Kubernetes Concepts: Difference between revisions
(→Label) |
|||
| Line 114: | Line 114: | ||
=Selector= | =Selector= | ||
{{Internal|OpenShift Concepts#Selector|OpenShift Selector}} | {{Internal|OpenShift Concepts#Selector|OpenShift Selector}} | ||
Revision as of 02:04, 6 July 2017
External
Internal
Overview
Kubernetes is an container orchestration platform, offering the ability of orchestrate Docker containers across multiple hosts. It manages containers in a clustered environment. It orchestrates containers at scale, defines application topologies, handles parts of the container networking, manages container state and schedules containers across hosts.
Master
Node
A node is a Linux container host.
It is based on RHEL or Red Hat Atomic and provides a runtime environment where applications run inside containers, which are contained in pods assigned by the master. Nodes are orchestrated by masters.
Nodes can be organized into many different topologies.
A node daemon runs on node each node.
What is the difference between the kubelet and the node daemon?
kube proxy daemons.
Pod
Storage
Persistent Volume
Represented by a PersistentVolume object. It is associated with a project.
An administrator provision persistent volumes from sources such as:
- NFS
- GCE Persistent Disks
- ESB Volumes
- GlusterFS
- OpenStack Cinder
- Ceph RBD
- iSCSI
- Fiber Channel
Storage resources are requested by laying a claim to the resource (PersistentVolumeClaim). A persistent volume claim is a request for a resource with a specific attributes. When a request is made, a process matches it to an available volume and binds them together. The runtime finds the volume bound to the claim and mounts it into the pod.
Persistent volumes can be recycled after use. The reclamation policy is based on the "persistentVolumeReclaimPolicy" declared in the PersistentVolume object definition. The policy can be "Retain" or "Recycle".
etcd
A distributed key/value datastore for state within the environment.
Scheduler
Namespace
A namespace provides scope for:
- named resources to avoid naming collisions
- delegating management authority to trusted users
- the ability to limit community resource consumption
Policies
Policies are rules that specify which users can and cannot specify actions on objects (pods, services, etc.).
Service
A service represents a group of pods, which may come and go, and its primary function is to provide the permanent IP, hostname and port for other applications to use. A service resource is an abstraction that defines a logical set of pods and a policy that is used to access the pods. The service layer is how applications communicate with one another.
The service serves as an internal load balancer: it identifies a set of replicated pods and then proxies the connections it receives to those pods (routers provide external load balancing).
The service is not a thing, but an entry in the configuration.
Backing pods can be added or removed to or from the service arbitrarily. This way, anything that depends on the service can refer to it as a consistent IP:port pair. The services uses a label selector to find all the running containers associated with it.
Service Definition File
API
Label
Selector
Replica
A replica is a set of pods sharing the same definition.
Replication Controller
A master component that insures a specified number of pod replicas defined in the environment state are running at all times. If pods exit or are deleted, the replication controller instantiates more pods up to desired number. If there are more pods running than desired, the replication controller deletes as many as necessary. It is NOT the replication controller's job to perform autoscaling based on load or traffic.
The definition of a replication controller includes the number of replicas to be maintained, the pod definition for creating the replicated pod, and a selector for identifying managed pods.