kubernetes-----pod调度约束

一.创建pod的过程

• Kubernetes通过watch的机制进行每个组件的协作，每个组件之间的设计实现了解耦

• 用户创建pod资源的过程：

用户使用命令kubectl create pod向apiserver请求创建pod，apisever接收到请求之后，将请求之中的pod属性信息写入etcd中。apiserver触发watch机制，向调度器发送创建pod的信息，调度器通过调度算法选择合适的node来创建pod，然后调度器又将node信息传递给apiserver，apiserver将node信息写入etcd当中。apiserver知道node信息后，通过watch机制，调用kubelet创建pod，kubelet使用docker run创建pod内部的容器，完成之后反馈给kubelet。pod创建完成之后，kubelet又将pod的状态信息反馈给apiserver，最后apiserver将pod的状态信息写入etcd当中。

其中，当我们使用kubectl get pod时，调用地是etcd的信息。

二.pod资源调度方式

• Kubernetes Master上的Scheduler服务（kube-scheduler进程）负责实现pod的调度，整个调度过程通过执行一系列复杂的算法，最终为每个pod都计算出一个最佳的目标节点，这一过程是自动完成的，通常我们无法知道pod最终会被调度到哪个节点之上。在实际情况之下，也可能需要将pod调度到一些指定的Node上，可以通过Node的标签（Label）和Pod的NodeSelector属性匹配，达到上述目的。
• 创建pod资源时，可以自定义node来创建
• 生产环境中可能会有区域性的node节点，需要不同节点创建不同服务，创建多副本时如果不约束调度，可能同一个服务会创建到不同的node上，这时候就需要约束调度来自定义node

nodeName

• 用于将pod调度到指定的Node名称上（跳过调度器直接分配）

实例如下：

• 编辑YAML文件

[root@master demo]# cat pod4.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-example
  labels:
    app: nginx
spec:
  nodeName: 192.168.43.103    ##指定node的名称
  containers:
  -name: nginx
  image: nginx:1.15
[root@master demo]# 

• 查看pod资源的创建过程

[root@master demo]# kubectl describe pods pod-example

• 查看pod与网络情况

[root@master demo]# kubectl get pods
NAME          READY   STATUS    RESTARTS   AGE
pod-example   1/1     Running   0          8m51s
[root@master demo]# kubectl get pods -o wide
NAME          READY   STATUS    RESTARTS   AGE     IP            NODE             NOMINATED NODE
pod-example   1/1     Running   0          8m55s   172.17.60.2   192.168.43.103   <none>
[root@master demo]# 

清空所有pod的命令，在yaml文件目录下执行：kubectl delete -f .

nodeSelector

• 用于将pod调度到匹配Label的Node上

实例如下

• 获取标签帮助

[root@master demo]# kubectl label --help
Update the labels on a resource. 
...
Examples:
  # Update pod 'foo' with the label 'unhealthy' and the value 'true'.
  kubectl label pods foo unhealthy=true
  
  # Update pod 'foo' with the label 'status' and the value 'unhealthy', overwriting any existing value.
  kubectl label --overwrite pods foo status=unhealthy
  
  # Update all pods in the namespace
  kubectl label pods --all status=unhealthy
  
  # Update a pod identified by the type and name in "pod.json"
  kubectl label -f pod.json status=unhealthy
  
  # Update pod 'foo' only if the resource is unchanged from version 1.
  kubectl label pods foo status=unhealthy --resource-version=1
  
  # Update pod 'foo' by removing a label named 'bar' if it exists.
  # Does not require the --overwrite flag.
  kubectl label pods foo bar-

Options:
...
Usage:
  kubectl label [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version] [options]
...
[root@master demo]# 

• 给node设置标签

[root@master demo]# kubectl get nodes
NAME             STATUS   ROLES    AGE   VERSION
192.168.43.102   Ready    <none>   14d   v1.12.3
192.168.43.103   Ready    <none>   14d   v1.12.3
[root@master demo]# kubectl label nodes 192.168.43.102 test=A
node/192.168.43.102 labeled
[root@master demo]# kubectl label nodes 192.168.43.103 test=B
node/192.168.43.103 labeled
[root@master demo]# 

• 查看node的标签

[root@master demo]# kubectl get nodes --show-labels
NAME             STATUS   ROLES    AGE   VERSION   LABELS
192.168.43.102   Ready    <none>   14d   v1.12.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=192.168.43.102,test=A
192.168.43.103   Ready    <none>   14d   v1.12.3   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=192.168.43.103,test=B
[root@master demo]# 

• 编辑YAML文件

[root@master demo]# cat pod4.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-example
  labels:
    app: nginx
spec:
  nodeSelector:       #选择nodeSelector，定向调度
    test: B         ##选择node标签
  containers:
  - name: nginx
    image: nginx:1.15
[root@master demo]# 

• 创建pod

[root@master demo]# kubectl apply -f pod4.yaml 
pod/pod-example created

• 查看详细事件

[root@master demo]# kubectl describe pod pod-example

• 查看pod网络，符合在yaml文件中定义的pod

[root@master demo]# kubectl get pods -o wide
NAME          READY   STATUS    RESTARTS   AGE     IP            NODE             NOMINATED NODE
pod-example   1/1     Running   0          2m55s   172.17.60.2   192.168.43.103   <none>
[root@master demo]# 

三.pod状态解析

• pod的状态

状态	描述
Running	该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。
Pending	Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间，这可能需要花点时间。创建pod的请求已经被k8s接受，但是容器并没有启动成功，可能处在：写数据到etcd，调度，pull镜像，启动容器这四个阶段中的任何一个阶段，pending伴随的事件通常会有：ADDED, Modified这两个事件的产生
Succeeded	Pod中的所有的容器已经正常的自行退出，并且k8s永远不会自动重启这些容器，一般会是在部署job的时候会出现。
Failed	Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。
Unknown	出于某种原因，无法获得Pod的状态，通常是由于与Pod主机通信时出错。

• pod详细的状态说明

状态	描述
CrashLoopBackOff	容器退出，kubelet正在将它重启
InvalidImageName	无法解析镜像名称
ImageInspectError	无法校验镜像
ErrImageNeverPull	策略禁止拉取镜像
ImagePullBackOff	正在重试拉取
RegistryUnavailable	连接不到镜像中心
ErrImagePull	通用的拉取镜像出错
CreateContainerConfigError	不能创建kubelet使用的容器配置
CreateContainerError	创建容器失败
m.internalLifecycle.PreStartContainer	执行hook报错
RunContainerError	启动容器失败
PostStartHookError	执行hook报错
ContainersNotInitialized	容器没有初始化完毕
ContainersNotRead	容器没有准备完毕
ContainerCreating	容器创建中
PodInitializing	pod 初始化中
DockerDaemonNotReady	docker还没有完全启动
NetworkPluginNotReady	网络插件还没有完全启动