Kubernetes Concepts: Difference between revisions
Line 19: | Line 19: | ||
A good high level abstraction for Kubernetes is that is a data center OS. The primary target of Kubernetes are containerized cloud-native applications, which are applications that are made from a set of small autonomous services (micro services) that communicate with each other. Kubernetes help deploying, scaling up, scaling down, performing updates and rollbacks of these services, handled as containers. | A good high level abstraction for Kubernetes is that is a data center OS. The primary target of Kubernetes are containerized cloud-native applications, which are applications that are made from a set of small autonomous services (micro services) that communicate with each other. Kubernetes help deploying, scaling up, scaling down, performing updates and rollbacks of these services, handled as containers. | ||
Kubernetes instances are known as <span id='Cluster'></span>Clusters. All interactions with a Kubernetes Cluster are performed by sending REST requests into an API Server. The API Server is responsible with managing and exposing the state of the Cluster. The state of the cluster is internally stored by a Cluster Store component, which is currently etcd. Externally, the state can be accessed and modified most commonly via a command line client named [[kubectl]]. The Cluster consists in a set of Nodes. There are Master Nodes and Worker Nodes. Each Node runs a [[Kubernetes Container Runtime Concepts|container runtime]], usually Docker. However, support for other container runtimes is available, via Container Runtime Interface (CRI). | Kubernetes instances are known as <span id='Cluster'></span>Clusters. All interactions with a Kubernetes Cluster are performed by sending REST requests into an API Server. The API Server is responsible with managing and exposing the state of the Cluster. The state of the cluster is internally stored by a Cluster Store component, which is currently etcd. Externally, the state can be accessed and modified most commonly via a command line client named [[kubectl]]. The Cluster consists in a set of Nodes. There are Master Nodes and Worker Nodes. Each Node runs a <span id='Container_Runtime'></span>[[Kubernetes Container Runtime Concepts|container runtime]], usually Docker. However, support for other container runtimes is available, via Container Runtime Interface (CRI). | ||
Worker Nodes are used to run workloads, as Pods - Pods are scheduled to Nodes and closely monitored. A Pod is the atomic unit of deployment in Kubernetes, and contains one or more containers. Pods come and go - if one Pod dies, it is not resurrected, but another Pod might be scheduled as replacement. In consequence, the IP address of an individual Pod cannot be relied on. To provide a stable access point to a set of equivalent Pods - which is how applications are deployed on Kubernetes, Kubernetes uses the concept of <span id='Service'></span>[[Kubernetes Service Concepts#Service|Service]], which can be thought of as stable networking for a continuously changing set of Pods. A Service's IP address and port can be relied on to be stable for the life of the Service. All live Pods represented by a Service at a moment in time are known as the Service's endpoint. There are several types of Services: ClusterIP, NodePort and LoadBalancer. The association between Services and Pods they expose is loose, established logically by the Service's Selector, which is a label-based mechanism: a Pod "belongs" to a Service if the Service's Selector matches the Pod's Labels. A Pod by itself has no built-in resilience: if it fails for any reason, it is gone. A higher level concept - the Deployment - is used to manage a set of Pods from a high availability perspective: the Deployment insures that a specific number of equivalent Pods is always running, and if one of more Pods fail, the Deployment brings up replacement Pods. The deployment relies on an intermediary concept - the Replica Set. Deployments are used to implement rolling updates and rollbacks. There are other resources that manage sets of Pods in different ways: DaemonSets and StatefulSets. Individual Pods can be managed as Jobs or CronJobs. | Worker Nodes are used to run workloads, as Pods - Pods are scheduled to Nodes and closely monitored. A Pod is the atomic unit of deployment in Kubernetes, and contains one or more containers. Pods come and go - if one Pod dies, it is not resurrected, but another Pod might be scheduled as replacement. In consequence, the IP address of an individual Pod cannot be relied on. To provide a stable access point to a set of equivalent Pods - which is how applications are deployed on Kubernetes, Kubernetes uses the concept of <span id='Service'></span>[[Kubernetes Service Concepts#Service|Service]], which can be thought of as stable networking for a continuously changing set of Pods. A Service's IP address and port can be relied on to be stable for the life of the Service. All live Pods represented by a Service at a moment in time are known as the Service's endpoint. There are several types of Services: ClusterIP, NodePort and LoadBalancer. The association between Services and Pods they expose is loose, established logically by the Service's Selector, which is a label-based mechanism: a Pod "belongs" to a Service if the Service's Selector matches the Pod's Labels. A Pod by itself has no built-in resilience: if it fails for any reason, it is gone. A higher level concept - the Deployment - is used to manage a set of Pods from a high availability perspective: the Deployment insures that a specific number of equivalent Pods is always running, and if one of more Pods fail, the Deployment brings up replacement Pods. The deployment relies on an intermediary concept - the Replica Set. Deployments are used to implement rolling updates and rollbacks. There are other resources that manage sets of Pods in different ways: DaemonSets and StatefulSets. Individual Pods can be managed as Jobs or CronJobs. |
Revision as of 17:25, 15 August 2019
External
Internal
TODO
Deplete Kubernetes Concepts TO DEPLETE.
Overview
Kubernetes is a container orchestration platform, or a container orchestrator. To understand how Kubernetes works is to understand a set of high level concepts, briefly mentioned here. More details on individual concepts are available on their respective pages.
A good high level abstraction for Kubernetes is that is a data center OS. The primary target of Kubernetes are containerized cloud-native applications, which are applications that are made from a set of small autonomous services (micro services) that communicate with each other. Kubernetes help deploying, scaling up, scaling down, performing updates and rollbacks of these services, handled as containers.
Kubernetes instances are known as Clusters. All interactions with a Kubernetes Cluster are performed by sending REST requests into an API Server. The API Server is responsible with managing and exposing the state of the Cluster. The state of the cluster is internally stored by a Cluster Store component, which is currently etcd. Externally, the state can be accessed and modified most commonly via a command line client named kubectl. The Cluster consists in a set of Nodes. There are Master Nodes and Worker Nodes. Each Node runs a container runtime, usually Docker. However, support for other container runtimes is available, via Container Runtime Interface (CRI).
Worker Nodes are used to run workloads, as Pods - Pods are scheduled to Nodes and closely monitored. A Pod is the atomic unit of deployment in Kubernetes, and contains one or more containers. Pods come and go - if one Pod dies, it is not resurrected, but another Pod might be scheduled as replacement. In consequence, the IP address of an individual Pod cannot be relied on. To provide a stable access point to a set of equivalent Pods - which is how applications are deployed on Kubernetes, Kubernetes uses the concept of Service, which can be thought of as stable networking for a continuously changing set of Pods. A Service's IP address and port can be relied on to be stable for the life of the Service. All live Pods represented by a Service at a moment in time are known as the Service's endpoint. There are several types of Services: ClusterIP, NodePort and LoadBalancer. The association between Services and Pods they expose is loose, established logically by the Service's Selector, which is a label-based mechanism: a Pod "belongs" to a Service if the Service's Selector matches the Pod's Labels. A Pod by itself has no built-in resilience: if it fails for any reason, it is gone. A higher level concept - the Deployment - is used to manage a set of Pods from a high availability perspective: the Deployment insures that a specific number of equivalent Pods is always running, and if one of more Pods fail, the Deployment brings up replacement Pods. The deployment relies on an intermediary concept - the Replica Set. Deployments are used to implement rolling updates and rollbacks. There are other resources that manage sets of Pods in different ways: DaemonSets and StatefulSets. Individual Pods can be managed as Jobs or CronJobs.
Storage.
Networking.
Security.
Subjects
Declarative versus Imperative Approach
API Resources
The full list of API resources available to interact with in Kubernetes is generated by:
kubectl api-resources
NAME SHORTNAMES APIGROUP NAMESPACED KIND bindings true Binding componentstatuses cs false ComponentStatus configmaps cm true ConfigMap endpoints ep true Endpoints events ev true Event limitranges limits true LimitRange namespaces ns false Namespace nodes no false Node persistentvolumeclaims pvc true PersistentVolumeClaim persistentvolumes pv false PersistentVolume pods po true Pod podtemplates true PodTemplate replicationcontrollers rc true ReplicationController resourcequotas quota true ResourceQuota secrets true Secret serviceaccounts sa true ServiceAccount services svc true Service mutatingwebhookconfigurations admissionregistration.k8s.io false MutatingWebhookConfiguration validatingwebhookconfigurations admissionregistration.k8s.io false ValidatingWebhookConfiguration customresourcedefinitions crd,crds apiextensions.k8s.io false CustomResourceDefinition apiservices apiregistration.k8s.io false APIService controllerrevisions apps true ControllerRevision daemonsets ds apps true DaemonSet deployments deploy apps true Deployment replicasets rs apps true ReplicaSet statefulsets sts apps true StatefulSet tokenreviews authentication.k8s.io false TokenReview localsubjectaccessreviews authorization.k8s.io true LocalSubjectAccessReview selfsubjectaccessreviews authorization.k8s.io false SelfSubjectAccessReview selfsubjectrulesreviews authorization.k8s.io false SelfSubjectRulesReview subjectaccessreviews authorization.k8s.io false SubjectAccessReview horizontalpodautoscalers hpa autoscaling true HorizontalPodAutoscaler cronjobs cj batch true CronJob jobs batch true Job certificatesigningrequests csr certificates.k8s.io false CertificateSigningRequest stacks compose.docker.com true Stack leases coordination.k8s.io true Lease events ev events.k8s.io true Event daemonsets ds extensions true DaemonSet deployments deploy extensions true Deployment ingresses ing extensions true Ingress networkpolicies netpol extensions true NetworkPolicy podsecuritypolicies psp extensions false PodSecurityPolicy replicasets rs extensions true ReplicaSet ingresses ing networking.k8s.io true Ingress networkpolicies netpol networking.k8s.io true NetworkPolicy runtimeclasses node.k8s.io false RuntimeClass poddisruptionbudgets pdb policy true PodDisruptionBudget podsecuritypolicies psp policy false PodSecurityPolicy clusterrolebindings rbac.authorization.k8s.io false ClusterRoleBinding clusterroles rbac.authorization.k8s.io false ClusterRole rolebindings rbac.authorization.k8s.io true RoleBinding roles rbac.authorization.k8s.io true Role priorityclasses pc scheduling.k8s.io false PriorityClass csidrivers storage.k8s.io false CSIDriver csinodes storage.k8s.io false CSINode storageclasses sc storage.k8s.io false StorageClass volumeattachments storage.k8s.io false VolumeAttachment