https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/
一级字段: apiVersion(group/version), kind, metadata(name,namespace,labels,annotations, ...), spec, status(只读)
1 Pod Template
Pod templates are pod specifications which are included in other objects, such as Replication Controllers, Jobs, and DaemonSets. Controllers use Pod Templates to make actual pods.
apiVersion: extensions/v1beta1 kind: Pod metadata: name: pod-demo namespace: default labels: app: myapp tier: frontend spec: containers: - name: myapp image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
- name: https
containerPort: 443
imagePullPolicy: IfNotPresent command: ["/bin/sh"] args: ["-c", "while true; do echo hello; sleep 10;done"]
nodeSelector:
disktype: ssd # only the node with label "disktype=ssd"
2. Metadata.
2.1 labels:
https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/#labels
You can visualize and manage Kubernetes objects with more tools than kubectl and the dashboard. A common set of labels allows tools to work interoperably, describing objects in a common manner that all tools can understand.
You can use labels to
- get the information about your resources like SQL select * from resource where label = / != / not in / in / etc. label-name
- deploy your application or service on special labeled node (such as deloy a deep learning model on the nodes with GPU, if you have GPU labeled nodes)
Labels are Key and Value pair:
- key can only contains alphabet, numbers, _, -, .
- value can only contains empty and must be started with alphabet or numbers. The rest is like key
pod.metadata.labels <map[string]string>
For example
apiVersion: apps/v1 kind: StatefulSet metadata: labels: app.kubernetes.io/name: mysql app.kubernetes.io/instance: wordpress-abcxzy app.kubernetes.io/version: "5.7.21" app.kubernetes.io/component: database app.kubernetes.io/part-of: wordpress app.kubernetes.io/managed-by: helm
Some useful example:
kubectl label pods pod-demo release=stable --overwrite # label pod with name pod-demo with label "release", which is stable. If label already exists, should be overwrite
kubectl get pods -l release --show-labels # show all pods with label "release" kubectl get pods -l release=stable # show all pods with label "release = stable" kubectl get pods -l release=stable,app=myapp # show all pods with labels release=stable,app=myapp
kubectl get pods -l "release in (canary,beta,alpha,app) # show all pods with label release, which release contains one from canary,beta,alpha,app
kubectl get pods -l "release notin (alpha, beta) # show all pods with label release, which dont contain alpha, beta
* Resources not Pod but e.g. Job, Deployment, Replica Set, and Daemon Set, support set-based requirements as well
For example as a part of deployment template, you can specify your to deployed pods should only be deployed on the nodes with predefined labels
such as deploy a application only on the nodes, which have SSD disks.
# part of deployment template
...
spec:
selector:
matchLabels:
disktype: SSD
...
-> deployment.spec.selector:
matchLabels:直接给定键值
matchExpressions:基于给定的表达式来定义使用标签选择器,{key:"KEY", operator:"OPERATOR", values:[VAL1,VAL2,...]}
操作符:
In, NotIn:values字段的值必须为非空列表;
Exists, NotExists:values字段的值必须为空列表;
2.2 Annotations
You can use Kubernetes annotations to attach arbitrary non-identifying metadata to objects. Clients such as tools and libraries can retrieve this metadata
https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
ou can use either labels or annotations to attach metadata to Kubernetes objects. Labels can be used to select objects and to find collections of objects that satisfy certain conditions. In contrast, annotations are not used to identify and select objects. The metadata in an annotation can be small or large, structured or unstructured, and can include characters not permitted by labels.
Annotations, like labels, are key/value maps:
"metadata": { "annotations": { "key1" : "value1", "key2" : "value2" } }
apiVersion: extensions/v1beta1 kind: Pod metadata: name: pod-demo namespace: default labels: app: myapp tier: frontend
annotations:
created-by: "cluster admin" spec: containers: - name: myapp image: ikubernetes/myapp:v1 ports: - name: http containerPort: 80 - name: https containerPort: 443 imagePullPolicy: IfNotPresent command: ["/bin/sh"] args: ["-c", "while true; do echo hello; sleep 10;done"] nodeSelector: disktype: ssd # only the node with label "disktype=ssd"
3. Spec
Specification of the desired behavior of the pod.
Some common and important attributes in Pod-Template:
pod.spec.containers <[] object>(requried)
pod.spec.containers.name <string> (requried)
pod.spec.containers.image <string>
pod.spec.nodeSelector <map[string]string> # deploy pod on the node with predefined label (see example)
pod.spec.nodeName <string> # deploy pod on the node with predefined label. Syntax is the same as nodeSelector
pod.spec.containers.command/args <[] string>
pod.spec.containers.ports <[] object> -> only a additional information for user, it is not a real expose of port number
pod.spec.containers.imagePullPolicy <string>
- Always -> always download image from registry (for example my local nginx image latest version is 14.1 and the latest nginx in docker hub is 14.3. Cause of Alway at starting a new Pod, Kubernetes will always try to download the latest from docker hub instead of using the local 14.1 as latest)
- Never -> only pull image from local, if docker image is not present on the machine, it won't download any thing
- ifNotPresent -> if image exsists locallly, it will be pulled from local otherwise will download from registry
These three options means for developer, if you always want to use the latest version of image, you must set imagePullPolicy to Always. If you only want to use the specified image, you must set imagePullPolicy to ifNotPresent (see: https://kubernetes.io/docs/concepts/containers/images/#updating-images)
4. Pod Lifecycle
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/
What will be happened, if a new pod is gonna to be created :
User send his "create pod" request to the apiserver, apiserver will store this request (target state of pod) in etcd. Then apiserver will aks Scheduler (scheduler knows, which node has the rerource for scheduling) for scheduling this new job and store the scheduled result (like on which worker-node is schedled this new job) in etcd. After this apiserver's state has been changed, the kubelet service of scheduled node will capture this new change and get the user generated target state from apiserver then create a new pod according to the target state request and send back the result (if a pod is successful created or not) to apiserver. Apiserver will finally save it in etcd.
See picture to understand the behavier in a pod livecycle
- Containers are initialized one by one.
- PostStart hook executes immediately after a container is created https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/
- After PostStart hook main container can perform two kinds of probes -> liveness probe, readiness probe ( see: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes) * liveness ( if all services in container are healthy then is this container live); readiness means that the container is ready to provide his service
- PreStop hook is called immediately before a container is terminated
5 Pod restartPolicy
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy
A PodSpec has a restartPolicy field with possible values Always, OnFailure, and Never. The default value is Always. restartPolicy applies to all Containers in the Pod. restartPolicy only refers to restarts of the Containers by the kubelet on the same node. Exited Containers that are restarted by the kubelet are restarted with an exponential back-off delay (10s, 20s, 40s …) capped at five minutes, and is reset after ten minutes of successful execution. As discussed in the Pods document, once bound to a node, a Pod will never be rebound to another node.
- Always (default): if one container is failed (error code not "0"), it must be restarted
- OnFailure: if the state of container is failure, it will be restarted
- Never: container just dies without restart
For example if a container exits after "sleep 10"
-> Always: this container will restart again
-> OnFailure: nothing happens, because container exists with 0
-> Never: nothing happens, even container terminated with code not 0