⒈
POD understanding
A plurality of containers together mirrors, and shared network namespace container volume
⒉
classification of pod
- Self-podv
Instead of being managed by the controller pod, it will not be once the death of people to pull together.
- Managed by the controller pod
It is managed by the controller pod
⒊
POD controller type
- ReplicationController referred RC
ReplicationController number of containers used to ensure that a copy of the application is always maintained at a user-defined number of copies, that is, if there is an abnormal exit pod, will automatically create a new pod in place; and if the abnormal extra pod will be automatically recovered. ReplicaSet recommended in the new version of Kubernetes in place of ReplicationController
- ReplicatSet referred RS
ReplicatSet with ReplicationController not essentially different, just a different name, ReplicaSet support the collective tag selector ReplicationController basis
- Deployment referred
Although ReplicaSet can be used independently, but generally it is recommended to use Deployment to automatically manage ReplicaSet, so no need to worry about with the incompatibilities other mechanisms (such as ReplicaSet does not support rolling-update [rollover] but Deployment Support), Deployment does not create a pod directly .
- Horizontal Pod Autoscaling referred smooth expansion] [HPA
Horizontal Pod Autoscaling only for Deployment and ReplicaSet, only supported in version V1 CPU utilization Pod according to the capacity expansion, in v1alpha version, the support and extended memory capacity metric according to user-defined.
- StatefulSet referred
StatefulSet to solve the problem of stateful services (and the corresponding Deployments ReplicaSets for stateless service design), its application scenarios include:
Persistent storage stable, i.e. after the rescheduling Pod or access to the same persistent data, based on the PVC to achieve
Stable network sign that the Pod reschedule its PodName and HostName unchanged, based on Headless Service (ie no Cluster IP of Service) to achieve
Orderly deployment, orderly expansion, i.e. Pod are ordered, sequentially according to the order defined sequentially at the time of deployment or extended (i.e., from 0 to N-1, all of the lower run until a Pod must both before Pod Running and Ready status), based init containers to achieve.
Orderly contraction order to remove (i.e., from N-1 to 0)
- DaemonSet referred
DaemonSet sure to run a copy of the Pod (Node) all (or some) node. When a new node joins the cluster will add a Pod for them. When a node is removed from the cluster, which will be recovered Pod. Delete DaemonSet will delete all it creates Pod
Use of some typical usage DaemonSet:
Run clustered storage daemon, for example, on each node glusterd, ceph
Collecting log daemon running on each node, e.g. fluentd, logstash
Running on each node monitoring daemon, e.g. Prometheus Node Exporter
- Job||Cromjob
Job responsible for batch jobs, that task is performed only once, it guarantees one or more batch jobs Pod successful conclusion.
Cron Job Management based on the time of Job, namely:
At a given point in time to run only once
Periodically run at a given point in time