November 04, 2018
Discover more insights on Kubernetes
Kubernetes is more than an orchestration system (Docker Swarm), it can be thought of as:
The technical definition of orchestration is execution of a defined workflow: first do A, then B, then C. In contrast, Kubernetes is comprised of a set of independent, composable control processes that continuously drive the current state towards the provided desired state. It shouldn’t matter how you get from A to C. Centralized control is also not required.
Master Components (cluster’s control plane)
Master components make global decisions about the cluster (for example, scheduling), detect and respond to cluster events. Usually master nodes do not host user containers.
Node Components
Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.
Addons
Addons are pods and services that implement cluster features. The pods may be managed by Deployments, ReplicationControllers, and so on.
Kubernetes Objects are persistent entities that represent the state of your cluster. By creating an object, you’re effectively telling the Kubernetes system what you want your cluster’s workload to look like, in another word, your cluster’s desired state.
Object spec describes your desired state for the object, which is the characteristics that you want the object to have. Object status describes the actual state of the object, which is supplied and managed by the Kubernetes Control Plane to match the desired state you supplied in spec.
Most often, Kubernetes object is described in a YAML file, and created via kubectl which converts the YAML file to JSON when making API requests to Kubernetes system.
kubectl create -f https://k8s.io/examples/application/deployment.yaml --record
Written by Warren who studies distributed systems at George Washington University. You might wanna follow him on Github