kubernetes Pod 控制器应用进阶

修改镜像中的默认应用：  command , args, env CMD 的区别；

标签：  key=value  key: 字母，数字 _ - value:可以为空，只能以字母或者数字开头及结尾，，中键可使用

在查看pod的类型的标签的时候使用lables

[root@server1 mainfests]# kubectl get pods --show-labels
NAME                          READY     STATUS         RESTARTS   AGE       LABELS
client                        0/1       Error          0          20h       run=client
myapp-848b5b879b-lj66h        1/1       Running        1          19h       pod-template-hash=4046164356,run=myapp
myapp-848b5b879b-tbnjb        1/1       Running        1          19h       pod-template-hash=4046164356,run=myapp
myapp-848b5b879b-tl78s        1/1       Running        1          19h       pod-template-hash=4046164356,run=myapp
nginx-deploy-5b595999-stvlq   1/1       Running        1          20h       pod-template-hash=16151555,run=nginx-deploy
pod-demo                      1/2       ErrImagePull   0          33s       app=myapp,tier=frontend

使用-L 显示拥有app标签的标签名和标签值,意思就是将含有app的标签的显示过来，但对其不进行过滤

[root@server1 mainfests]# kubectl get pods -L app
NAME                          READY     STATUS    RESTARTS   AGE       APP
client                        0/1       Error     0          20h       
myapp-848b5b879b-lj66h        1/1       Running   1          19h       
myapp-848b5b879b-tbnjb        1/1       Running   1          19h       
myapp-848b5b879b-tl78s        1/1       Running   1          19h       
nginx-deploy-5b595999-stvlq   1/1       Running   1          20h       
pod-demo                      2/2       Running   0          46s       myapp

-l 是用来标签过滤的，使用这一类的标签pod的对象

[root@server1 mainfests]# kubectl get pods -l app
NAME       READY     STATUS    RESTARTS   AGE
pod-demo   2/2       Running   0          3m

[root@server1 mainfests]# kubectl get pods -l app --show-labels
NAME       READY     STATUS    RESTARTS   AGE       LABELS
pod-demo   2/2       Running   0          4m        app=myapp,tier=frontend

[root@server1 mainfests]# kubectl get pods -L app,run
NAME                          READY     STATUS    RESTARTS   AGE       APP       RUN
client                        0/1       Error     0          20h                 client
myapp-848b5b879b-lj66h        1/1       Running   1          19h                 myapp
myapp-848b5b879b-tbnjb        1/1       Running   1          19h                 myapp
myapp-848b5b879b-tl78s        1/1       Running   1          19h                 myapp
nginx-deploy-5b595999-stvlq   1/1       Running   1          20h                 nginx-deploy
pod-demo                      2/2       Running   0          6m        myapp     

修改资源的标签：

对已经存在的资源打标签，标签存在的形式是以key=value存在， key可以称为标签，后面可以称为标签名

[root@server1 mainfests]# kubectl label pods pod-demo release=canary
pod/pod-demo labeled

[root@server1 mainfests]# kubectl get pods -l app --show-labels
NAME       READY     STATUS    RESTARTS   AGE       LABELS
pod-demo   2/2       Running   0          11m       app=myapp,release=canary,tier=frontend

如何改变其中的某一个标签的value值，例如：将release的值从canary改为stable

注意：不能对已经存放的标签的值进行强行的改变，会报错，如下图所示

[root@server1 mainfests]# kubectl label pods pod-demo release=stable
error: 'release' already has a value (canary), and --overwrite is false

根据错误的提示，我们要使用额外的参数来改变 --overwrite  称为额外覆盖

[root@server1 mainfests]# kubectl label pods pod-demo release=stable --overwrite
pod/pod-demo labeled

[root@server1 mainfests]# kubectl get pods -l app --show-labels
NAME       READY     STATUS    RESTARTS   AGE       LABELS
pod-demo   2/2       Running   0          15m       app=myapp,release=stable,tier=frontend

[root@server1 mainfests]# kubectl get pods -l release,app
NAME       READY     STATUS    RESTARTS   AGE
pod-demo   2/2       Running   0          28m

指定具体的标签的值，来指定标签选择器 ， k8s标签选择器：  1.等值关系：=，== ，！=    2.集合关系：KEY IN （VALUE1 VALUE2）KEY NOT IN （VALUE1 VALUE2 ） ！KEY 不存在此键的资源

[root@server1 mainfests]# kubectl get pods -l release=stable --show-labels
NAME       READY     STATUS    RESTARTS   AGE       LABELS
pod-demo   2/2       Running   0          31m       app=myapp,release=stable,tier=frontend

在多个标签带值过滤的过程中，这些标签必须同时满足，因为他们属于同一个逻辑域

[root@server1 mainfests]# kubectl get pods -l release=stable,app=myapp
NAME       READY     STATUS    RESTARTS   AGE
pod-demo   2/2       Running   0          34m

基于集合的关系的标签的过滤

[root@server1 mainfests]# kubectl get pods -l "release in (canary,beta,alpha)"
NAME                          READY     STATUS    RESTARTS   AGE
nginx-deploy-5b595999-stvlq   1/1       Running   1          22h

[root@server1 mainfests]# kubectl get pods -l "release notin (canary,beta,alpha)" --show-labels
NAME                     READY     STATUS    RESTARTS   AGE       LABELS
client                   0/1       Error     0          22h       run=client
myapp-848b5b879b-lj66h   1/1       Running   1          21h       pod-template-hash=4046164356,run=myapp
myapp-848b5b879b-tbnjb   1/1       Running   1          21h       pod-template-hash=4046164356,run=myapp
myapp-848b5b879b-tl78s   1/1       Running   1          21h       pod-template-hash=4046164356,run=myapp
pod-demo                 2/2       Running   1          1h        app=myapp,release=stable,tier=frontend

使用标签选择器关联其他资源的，实现标签的关联   许多资源支持内嵌字段定义其使用的标签选择器：

matshlabels:       直接给定键值              

matchExpressions:  基于给定的表达式来定义使用标签选择器 {key:"KEY", operator:"OPERATOR", value:"[VALUE1 VALUE2 VALUE3 ...]}

操作符： In Notin : (VALUE 字段的值必须为非空列表）        Exists NotExists   （其值必须为列表VALUE )

[root@server1 mainfests]# kubectl get nodes --show-labels
NAME      STATUS    ROLES     AGE       VERSION   LABELS
server1   Ready     master    1d        v1.11.1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=server1,node-role.kubernetes.io/master=
server2   Ready         1d        v1.11.1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=server2
server3   Ready         1d        v1.11.1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=server3

[root@server1 mainfests]# kubectl  label nodes server2 disktype=ssd
node/server2 labeled

[root@server1 mainfests]# kubectl get nodes --show-labels
NAME      STATUS    ROLES     AGE       VERSION   LABELS
server1   Ready     master    1d        v1.11.1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=server1,node-role.kubernetes.io/master=
server2   Ready         1d        v1.11.1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disktype=ssd,kubernetes.io/hostname=server2
server3   Ready         1d        v1.11.1   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=server3

nodeSelecter    节点标签选择器 ，确定pod运行在那类节点上，指定pod对象运行在那类的节点之上

那么指定具体的pod运行在那类的节点之上需要在其资源定义清单的yaml文件中写入参数：

编写你的pod-demon.yaml的文件，在spec下编写容器创建对节点选择的参数：

spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
    ports:
    - name: http
      containerPort: 80
    - name: https
      containerPort: 443
  - name: busybox
    image: busybox:latest
    imagePullPolicy: IfNotPresent
    command:
    - "/bin/sh"
    - "-c"
    - "sleep 3600"
  nodeSelector:
    disktype: ssd

[root@server1 mainfests]# kubectl create -f pod-demo.yaml
pod/pod-demo created
[root@server1 mainfests]# kubectl get pods -o wide
NAME                          READY     STATUS    RESTARTS   AGE       IP            NODE
client                        0/1       Error     0          22h       10.244.2.4    server3
myapp-848b5b879b-lj66h        1/1       Running   1          21h       10.244.1.12   server2
myapp-848b5b879b-tbnjb        1/1       Running   1          21h       10.244.2.15   server3
myapp-848b5b879b-tl78s        1/1       Running   1          21h       10.244.2.12   server3
nginx-deploy-5b595999-stvlq   1/1       Running   1          22h       10.244.2.14   server3
pod-demo                      2/2       Running   0          9s        10.244.1.16   server2

就会发现那么我们利用yaml文件定义的pod对象只在含有标签为disktype: ssd 的node节点上部署pod 对象

那么在还有其他的标签指定的参数，nodeName 指明指定的哪个节点上创建pod对象  nodeName

annotations:    与label不同的地方在于，它不能用于挑选资源对象，仅用于为对象提供“元数据”。

那么重新编写资源定义的清单的yaml文件，添加annotations的标签。

metadata:
  name: pod-demo
  namespace: default
  labels:
    app: myapp
    tier: frontend
  annotations:
    magedu.com/created-by: "cluster admin"

[root@server1 mainfests]# kubectl describe pods pod-demo
Name:               pod-demo
Namespace:          default
Priority:           0
PriorityClassName: 
Node:               server2/172.25.254.2
Start Time:         Sat, 04 May 2019 19:35:20 +0800
Labels:             app=myapp
                    tier=frontend
Annotations:        magedu.com/created-by=cluster admin      资源注解

在pod内部 pod是有声明周期的，对pod而言，

一个容器只能运行一个进程，在一个pod内部可以运行多个容器，但是一般只运行一个容器，或者是有主容器和相关的辅助容器

pod中的容器在运行之前要进行环境设定，一般主容器启动之前，可以用来干别的事情，一般可以运行一个专门为主容器做环境初始化的容器 ，初始化的容器一旦完成了以后，就会退出，但是初始化的容器有时不止一个，多个初始化的容器是要串行执行的，

另外在主容器启动的时候，也需要自己在应用程序启动的时候初始化，main container 刚刚启动后 ，用户可以手动嵌入做一些操作

Pod 的生命周期：  状态： Pending 挂起   Running  成功 Failed 失败   Succeedes  Unknown 

创建 Pod 经历的阶段： 当用户创建Pod 时这个请求会提交给api server , api server会先把创建的请求保存在etcd 中 ，而后api server 会请求schelder 进行调度，并且调度成功的话，把调度的结果保存在etcd 中 目标资源的pod信息当中，随后调度到node节点上 ，node节点上的kubelet 根据api server的状态的变化会知道 有一个新任务给自己 ，所以此时kubelet 会拿到用户创建的清单 ，根据清单在当前的节点上去运行一个pod ,那么运行成功或者失败会有一个状态，这个状态的成功或者失败作为pod的状态的返回会发回给api server ，那么api server会把此时的pod的状态存储在etcd当中 。

这是pod生命周期中的第二种行为，这是容器的探测，有两种：

存活性探测主要用于对主容器判断其是否处于运行状态，而就绪性探测是判定容器中的主进程是否已经准备就绪并可以对外提供服务的，一旦主容器处于Running状态 而后就表示其存活性探测是成功的，容器存活并不意味着容器可以对外提供服务，那么在k8s上分别对两种进行探测 ，那么docker 不需要探测第一种，因为一旦容器不存在那么这个容器的生命周期就结束了 ，那么k8s内pod可以存在多个容器，一个容器结束，并不意味着pod会截止，那么为了探测具体的某一个容器，或者主容器是否正常，那么我们应该对容器进行存活性探测 ，要使用 liveness probe ,探测方式有三种我们可以直接使用命令来进行探测 ，比如ps 一下 看某个进程在不在，那么进程在其就是存活的，这就是一种方式，也可以向tcp的套接字发请求，判断其是否可以正常的连接，要不然可以向http的服务发请求。

总结： pod 生命周期种的重要行为： 

1.初始化容器   ：  比较复杂在后面的将会说到

2.容器探测    ：  liveness probe     容器是否存活          readliness probe   容器是否可以提供正常的服务

3. 启动后钩子  ：  只是容器启动前的一个示例，包含启动前钩子

 

下面我们说一说容器的重启策略：

  那么做存活性探测时候发现一个容器挂了，pod还在运行，那么此时容器要不要重启？

  因此下来要说的pod中的另外一个字段  < < restartPolicy > > 重启策略  ：那么重启策略有三种，我们一一说到：

定义容器的重启策略那么对pod而言时很关键的；

那么一旦一个pod被调度至某一节点上，那么在pod存在周期内是不会被重新调度的，只能重启，除非这个pod被删除那么会重新调度，除非这个节点挂了，那么才会重新被调度，某则一旦调度那么pod会被一直在节点上重启，

    1. Always  （总是重启）, 2.OnFailure,（只有其状态为错误时才会重启） 3.Never, （从不重启）4.Default to Always （  ）

pod的终止过程，本身代表在k8s节点上运行的程序或者进程，那么有可能是向用户提供的主要单位，那么pod一旦发生故障的时候，我们应该将其平滑的加载至别的节点，因此在提交深处pod时，是不会被已开始就kill掉，而是向pod 内的每个容器发送结束，或者终止信号，让pod中的容器正常的终止，会给容器一个宽限期，可能是30s，那么在30s内必须要平滑的正常的终止，那么在宽限期内没有正常的终止的情况下，会重新发送kill信号 ，第一次发送的是别的信号，那么一般默认的宽限期是30s，因此整个pod的生命周期从创建到截至 ，整个过程是周期性的，要经常做探测，一旦要删除一个pod要平滑的终止一个pod。这是pod生命周期的几个重要行为。