Difference between revisions of "Kubernetes Concepts"

From NovaOrdis Knowledge Base
Jump to: navigation, search
(Overview)
(Overview)
(2 intermediate revisions by the same user not shown)
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.
+
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.
  
 
Storage.
 
Storage.
 +
 +
Networking.
  
 
Security.
 
Security.
 +
 +
=Subjects=
 +
 +
* [[Kubernetes Container Runtime Concepts|Container Runtime Concepts]]
 +
* [[Kubernetes Service Concepts|Service Concepts]]
  
 
=Declarative versus Imperative Approach=
 
=Declarative versus Imperative Approach=

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