标签：容器 container 标签 概念 io pod pods

pod的持久性

一般来说，用户不需要直接创建 Pod。他们几乎都是使用控制器进行创建，即使对于单例的 Pod 创建也一样使用控制器，例如Deployments控制器提供集群范围的自修复以及副本数和滚动管理。 像StatefulSet这样的控制器还可以提供支持有状态的Pod。

pod生命周期

同一个pod中可以运行多个容器，我们在创建一个pod时可以通过创建多个容器来实现pod的整个生命周期，一个pod的创建包含如下过程：

Init容器（也叫做初始化容器）：

Init容器就是做初始化工作的容器。可以有一个或多个，如果多个按照定义的顺序依次执行，只有所有的初始化容器执行完后，主容器才启动。由于一个Pod里的存储卷是共享的，所以Init Container里产生的数据可以被主容器使用到，Init Container可以在多种K8S资源里被使用到，如Deployment、DaemonSet, StatefulSet、Job等，但都是在Pod启动时，在主容器启动前执行，做初始化工作。

主容器：

容器钩子：

对于pod资源来说，容器钩子是在pods.spec.containers.lifecycle下定义的

初始化容器启动之后，开始启动主容器，在主容器启动之前有一个post start hook（容器启动后钩子）和pre stop hook（容器结束前钩子）

postStart：该钩子在容器被创建后立刻触发，通知容器它已经被创建。如果该钩子对应的hook handler执行失败，则该容器会被杀死，并根据该容器的重启策略决定是否要重启该容器，这个钩子不需要传递任何参数

preStop：该钩子在容器被删除前触发，其所对应的hook handler必须在删除该容器的请求发送给Docker daemon之前完成。在该钩子对应的hook handler完成后不论执行的结果如何，Docker daemon会发送一个SGTERN信号量给Docker daemon来删除该容器，这个钩子不需要传递任何参数

#查看postStart怎么定义的，可以用如下命令：

[root@master-1 ~]# kubectl explain  pods.spec.containers.lifecycle.postStart
KIND:     Pod
VERSION:  v1

RESOURCE: postStart <Object>

DESCRIPTION:
     PostStart is called immediately after a container is created. If the
     handler fails, the container is terminated and restarted according to its
     restart policy. Other management of the container blocks until the hook
     completes. More info:
     https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks

     Handler defines a specific action that should be taken

FIELDS:
   exec	<Object>
     One and only one of the following should be specified. Exec specifies the
     action to take.

   httpGet	<Object>
     HTTPGet specifies the http request to perform.

   tcpSocket	<Object>
     TCPSocket specifies an action involving a TCP port. TCP hooks not yet
     supported

　　#查看preStop怎么定义的，可以用如下命令：

[root@master-1 ~]# kubectl explain  pods.spec.containers.lifecycle.preStop
KIND:     Pod
VERSION:  v1

RESOURCE: preStop <Object>

DESCRIPTION:
     PreStop is called immediately before a container is terminated due to an
     API request or management event such as liveness/startup probe failure,
     preemption, resource contention, etc. The handler is not called if the
     container crashes or exits. The reason for termination is passed to the
     handler. The Pod's termination grace period countdown begins before the
     PreStop hooked is executed. Regardless of the outcome of the handler, the
     container will eventually terminate within the Pod's termination grace
     period. Other management of the container blocks until the hook completes
     or until the termination grace period is reached. More info:
     https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks

     Handler defines a specific action that should be taken

FIELDS:
   exec	<Object>
     One and only one of the following should be specified. Exec specifies the
     action to take.

   httpGet	<Object>
     HTTPGet specifies the http request to perform.

   tcpSocket	<Object>
     TCPSocket specifies an action involving a TCP port. TCP hooks not yet
     supported

　　容器探针：

livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为Success。

readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success

[root@master-1 ~]# kubectl explain pods.spec.containers.livenessProbe
KIND:     Pod
VERSION:  v1

RESOURCE: livenessProbe <Object>

DESCRIPTION:
     Periodic probe of container liveness. Container will be restarted if the
     probe fails. Cannot be updated. More info:
     https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

     Probe describes a health check to be performed against a container to
     determine whether it is alive or ready to receive traffic.

FIELDS:
   exec	<Object>
     One and only one of the following should be specified. Exec specifies the
     action to take.

   failureThreshold	<integer>
     Minimum consecutive failures for the probe to be considered failed after
     having succeeded. Defaults to 3. Minimum value is 1.

   httpGet	<Object>
     HTTPGet specifies the http request to perform.

   initialDelaySeconds	<integer>
     Number of seconds after the container has started before liveness probes
     are initiated. More info:
     https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

   periodSeconds	<integer>
     How often (in seconds) to perform the probe. Default to 10 seconds. Minimum
     value is 1.

   successThreshold	<integer>
     Minimum consecutive successes for the probe to be considered successful
     after having failed. Defaults to 1. Must be 1 for liveness and startup.
     Minimum value is 1.

   tcpSocket	<Object>
     TCPSocket specifies an action involving a TCP port. TCP hooks not yet
     supported

   timeoutSeconds	<integer>
     Number of seconds after which the probe times out. Defaults to 1 second.
     Minimum value is 1. More info:
     https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

　　#查看readinessProbe帮助命令：

[root@master-1 ~]# kubectl explain pods.spec.containers.readinessProbe
KIND:     Pod
VERSION:  v1

RESOURCE: readinessProbe <Object>

DESCRIPTION:
     Periodic probe of container service readiness. Container will be removed
     from service endpoints if the probe fails. Cannot be updated. More info:
     https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

     Probe describes a health check to be performed against a container to
     determine whether it is alive or ready to receive traffic.

FIELDS:
   exec	<Object>
     One and only one of the following should be specified. Exec specifies the
     action to take.

   failureThreshold	<integer>
     Minimum consecutive failures for the probe to be considered failed after
     having succeeded. Defaults to 3. Minimum value is 1.

   httpGet	<Object>
     HTTPGet specifies the http request to perform.

   initialDelaySeconds	<integer>
     Number of seconds after the container has started before liveness probes
     are initiated. More info:
     https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

   periodSeconds	<integer>
     How often (in seconds) to perform the probe. Default to 10 seconds. Minimum
     value is 1.

   successThreshold	<integer>
     Minimum consecutive successes for the probe to be considered successful
     after having failed. Defaults to 1. Must be 1 for liveness and startup.
     Minimum value is 1.

   tcpSocket	<Object>
     TCPSocket specifies an action involving a TCP port. TCP hooks not yet
     supported

   timeoutSeconds	<integer>
     Number of seconds after which the probe times out. Defaults to 1 second.
     Minimum value is 1. More info:
     https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

　　

常见的pod状态

[root@master-1 ~]# kubectl get pods chenxi-dev
NAME         READY   STATUS    RESTARTS   AGE
chenxi-dev   （成功的容器个数）1/1(pod容器个数)     Running   0          73m

　　

（1）Pending：挂起，我们在请求创建pod时，条件不满足，调度没有完成，没有任何一个节点能满足调度条件。已经创建了但是没有适合它运行的节点叫做挂起，调度没有完成。

（2）Running：运行状态

（3）Failed：表示失败

（4）Succeeded：表示成功状态

（5）Unknown：未知状态，所谓pod是什么状态是apiserver和运行在pod节点的kubelet进行通信获取状态信息的，如果节点之上的kubelet本身出故障，那么apiserver就连不上kubelet，得不到信息了，就会看Unknown

创建pod时大概经历哪些阶段：

初始化容器-->主容器

pod重启策略

Always：只要容器挂了就重启

OnFailure：只有容器状态为错误的时候才重启

Never：从不重启容器

默认重启策略就是Always

 #查看重启策略restartPolicy怎么定义的：

[root@master-1 ~]# kubectl explain pods.spec.restartPolicy
KIND:     Pod
VERSION:  v1

FIELD:    restartPolicy <string>

DESCRIPTION:
     Restart policy for all containers within the pod. One of Always, OnFailure,
     Never. Default to Always. More info:
     https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy

　　名称空间-namespace

namespace叫做命名空间，可以把k8s集群划分成多个名称空间，然后对不同的名称空间的资源做隔离，可以控制各个名称空间的入栈，出栈策略，是一种在多个用户之间划分群集资源的方法

#查看k8s集群当前有哪些名称空间：

[root@master-1 ~]# kubectl get ns
NAME              STATUS   AGE
default           Active   2d15h
kube-node-lease   Active   2d15h
kube-public       Active   2d15h
kube-system       Active   2d15h

　pod label

（1）什么是标签？

标签其实就一对 key/value ，被关联到对象上，比如Pod,标签的使用我们倾向于能够标示对象的特殊特点，并且对用户而言是有意义的（就是一眼就看出了这个Pod是干什么的），标签可以用来划分特定组的对象（比如版本，服务类型等），标签可以在创建一个对象的时候直接给与，也可以在后期随时修改，每一个对象可以拥有多个标签，但是，key值必须是唯一的

（2）查看所有pod资源对象的标签

[root@master-1 ~]# kubectl get pods --show-labels
NAME         READY   STATUS    RESTARTS   AGE    LABELS
chenxi-dev   1/1     Running   0          84m    dev=chenxi
demo-pod     2/2     Running   50         2d2h   app=myapp,env=dev

（3）查看带有指定标签的pod

[root@master-1 ~]# kubectl get pods -l dev --show-labels 
NAME         READY   STATUS    RESTARTS   AGE   LABELS
chenxi-dev   1/1     Running   0          86m   dev=chenxi
查看拥有dev这个标签的资源对象，并且把标签显示出来

　　（5）想修改资源的标签，比方说想给chenxi-dev上个release标签

给资源对象打标签要使用label命令，指定给某个类型下的某个资源打标签，资源中的key/value可以是多个，因此在chenxi-dev（pod名字）这个资源下再打个标签release，用如下命令

[root@master-1 ~]# kubectl label pods chenxi-dev release=new
pod/chenxi-dev labeled
您在 /var/spool/mail/root 中有新邮件
[root@master-1 ~]# kubectl get pods -l dev --show-labels 
NAME         READY   STATUS    RESTARTS   AGE   LABELS
chenxi-dev   1/1     Running   0          90m   dev=chenxi,release=new
[root@master-1 ~]# kubectl get pods -l release --show-labels 
NAME         READY   STATUS    RESTARTS   AGE   LABELS
chenxi-dev   1/1     Running   0          90m   dev=chenxi,release=new

标签选择器：

与name和UID不同，label不提供唯一性。通常，我们会看到很多对象有着一样的label。通过标签选择器，客户端/用户能方便辨识出一组对象。

API目前支持两种标签选择器：基于等值的和基于集合的标签选择器。一个label选择器可以由多个必须条件组成，由逗号分隔。在多个必须条件指定的情况下，所有的条件都必须满足，因而逗号起着AND逻辑运算符的作用。

一个空的label选择器（即有0个必须条件的选择器）会选择集合中的每一个对象。

一个null型label选择器（仅对于可选的选择器字段才可能）不会返回任何对象。

基于等值关系的标签选择器：

=，==，!=

基于相等性或者不相等性的条件允许用label的键或者值进行过滤。匹配的对象必须满足所有指定的label约束，尽管他们可能也有额外的label。有三种运算符是允许的，“=”，“==”和“!=”。前两种代表相等性（他们是同义运算符），后一种代表非相等性。例如：

environment = production tier != frontend

第一个选择所有键等于 environment 值为 production 的资源。后一种选择所有键为 tier 值不等于 frontend 的资源，和那些没有键为 tier 的label的资源。

要过滤所有处于 production 但不是 frontend 的资源，可以使用逗号操作符， environment=production,tier!=frontend 。

第二类叫做基于集合的标签选择器：

基于集合的label条件允许用一组值来过滤键。支持三种操作符: in ， notin ,和 exists(仅针对于key符号) 。例如：

environment in (production, qa)

tier notin (frontend, backend)

第一个例子，选择所有键等于 environment ，且value等于 production 或者 qa 的资源。 第二个例子，选择所有键等于tier且值是除了frontend 和 backend 之外的资源，和那些没有label的键是 tier 的资源。 类似的，逗号操作符相当于一个AND操作符。因而要使用一个 partition 键（不管值是什么），并且 environment 不是 qa 过滤资源可以用 partition,environment notin (qa) 。

基于集合的选择器是一个相等性的宽泛的形式，因为 environment=production 相当于environment in (production) ，与 != and notin 类似。

基于集合的条件可以与基于相等性 的条件混合。例如， partition in (customerA,customerB),environment != qa 。

标签选择器根据定义的标签可以选择匹配到的资源对象

node label

（1）查看nodes节点的标签

[root@master-1 ~]# kubectl get nodes --show-labels
NAME     STATUS   ROLES    AGE     VERSION   LABELS
node-1   Ready    <none>   2d15h   v1.20.7   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-1,kubernetes.io/os=linux

　　

（2）给node节点打标签：

[root@master-1 ~]# kubectl get nodes --show-labels
NAME     STATUS   ROLES    AGE     VERSION   LABELS
node-1   Ready    <none>   2d15h   v1.20.7   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-1,kubernetes.io/os=linux,node011=chenxi

可以看到node-1上有node011这个标签了

（3）节点选择器nodeSelector

#查看nodeSelector帮助命令

[root@master-1 ~]# kubectl explain pods.spec.nodeSelector
KIND:     Pod
VERSION:  v1

FIELD:    nodeSelector <map[string]string>

DESCRIPTION:
     NodeSelector is a selector which must be true for the pod to fit on a node.
     Selector which must match a node's labels for the pod to be scheduled on
     that node. More info:
     https://kubernetes.io/docs/concepts/configuration/assign-pod-node/
#这个node011是我们给node-1节点打的标签，在上面已经操作过
cat pod.yaml 看到完整的文件如下：
apiVersion: v1
kind: Pod
metadata:
  name: web
  namespace: default
  labels:
    web1: tomcat
spec:
  containers:
  - name: tomcat1
    image: tomcat:8.5-jre8-alpine
  nodeSelector：
    node011：haha
kubectl delete -f pod.yaml
kubectl apply -f pod.yaml 
kubectl get pods -o wide 

　　

标签：容器,container,标签,概念,io,pod,pods
来源： https://www.cnblogs.com/rdchenxi/p/16585151.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。