深入理解pod

pod定义详解

 

apiVersion: v1 //版本 kind: pod //类型，pod metadata: //元数据  name: String //元数据，pod的名字  namespace: String //元数据，pod的命名空间  labels: //元数据，标签列表  - name: String //元数据，标签的名字  annotations: //元数据,自定义注解列表  - name: String //元数据,自定义注解名字 spec: //pod中容器的详细定义  containers: //pod中的容器列表，可以有多个容器  - name: String  image: String //容器中的镜像  imagesPullPolicy: [Always|Never|IfNotPresent]//获取镜像的策略  command: [String] //容器的启动命令列表（不配置的话使用镜像内部的命令）  args: [String] //启动参数列表  workingDir: String //容器的工作目录  volumeMounts: //挂载到到容器内部的存储卷设置  - name: String  mountPath: String  readOnly: boolean  ports: //容器需要暴露的端口号列表  - name: String  containerPort: int //容器要暴露的端口  hostPort: int //容器所在主机监听的端口（容器暴露端口映射到宿主机的端口）  protocol: String  env: //容器运行前要设置的环境列表  - name: String  value: String  resources: //资源限制  limits:  cpu: Srting  memory: String  requeste:  cpu: String  memory: String  livenessProbe: //pod内容器健康检查的设置  exec:  command: [String]  httpGet: //通过httpget检查健康  path: String  port: number  host: String  scheme: Srtring  httpHeaders:  - name: Stirng  value: String  tcpSocket: //通过tcpSocket检查健康  port: number  initialDelaySeconds: 0//首次检查时间  timeoutSeconds: 0 //检查超时时间  periodSeconds: 0 //检查间隔时间  successThreshold: 0  failureThreshold: 0  securityContext: //安全配置  privileged: falae  restartPolicy: [Always|Never|OnFailure]//重启策略  nodeSelector: object //节点选择  imagePullSecrets:  - name: String  hostNetwork: false //是否使用主机网络模式，默认否  volumes: //在该pod上定义共享存储卷  - name: String  meptyDir: {}  hostPath:  path: string  secret: //类型为secret的存储卷  secretName: String  item:  - key: String  path: String  configMap: //类型为configMap的存储卷  name: String  items:  - key: String  path: String

 

pod的特点

• 最小部署单元 

• 一组容器的集合

• 一个Pod中的容器共享网络命名空间 puase

• Pod是短暂的 （重拉pod ip会发生变化）

pod由于有个根容器pause，所以pod中的其他容器可以共享网络 和 存储

示例：share-volume.yaml

说明，两个centos容器write和read   

write容器：向 /data/hello 文件每隔1秒追加1到100数字

read容器： tailf -f /data/hello  

效果：查看write 容器中的/data/hello文件是不断写入，查看read容器 /data/hello 也是不断写入的

说明：同一个pod中的容器 共享存储，共享网络

apiVersion: v1 kind: Pod metadata:  name: my-pod spec:  containers:  - name: write  image: centos  command: ["bash","-c","for i in {1..100};do echo $i >> /data/hello;sleep 1;done"]  volumeMounts:  - name: data  mountPath: /data  - name: read  image: centos  command: ["bash","-c","tail -f /data/hello"]  volumeMounts:  - name: data  mountPath: /data  volumes:  - name: data  emptyDir: {}

pod应用场景

• Pod为亲密性应用而存在。 亲密性应用场景：

• 两个应用之间发生文件交互

• 两个应用需要通过127.0.0.1或者socket通信

• 两个应用需要发生频繁的调用

 

镜像拉取策略（imagePullPolicy）

• IfNotPresent：默认值，镜像在宿主机上不存在时才拉取

• Always：每次创建 Pod 都会重新拉取一次镜像

• Never： Pod 永远不会主动拉取这个镜像

 

apiVersion: v1 kind: Pod metadata:  name: foo  namespace: awesomeapps spec:  containers:  - name: foo  image: janedoe/awesomeapp:v1  imagePullPolicy: IfNotPresent 

 

apiVersion: v1 kind: Pod metadata:  name: foo  namespace: awesomeapps spec:  containers:  - name: foo  image: janedoe/awesomeapp:v1  imagePullSecrets:  - name: myregistrykey

如果使用私有仓库需要定义一个secret 用于存放登录registry仓库的信息

 kubectl create secret docker-registry myregistry --docker-username=benjamin7788 --docker-password=a7260488 --docker-server=registry.cn-hangzhou.aliyuncs.com -n awesomeapps 

 

pod的资源限制

• spec.containers[].resources.limits.cpu

• spec.containers[].resources.limits.memory

• spec.containers[].resources.requests.cpu

• spec.containers[].resources.requests.memory

 

kubernetes会根据Request的值去查找有足够资源的node来调度此pod

limit对应资源量的上限, 既最多允许使用这个上限的资源量, 由于cpu是可压缩的, 进程是无法突破上限的, 而memory是不可压缩资源, 当进程试图请求超过limit限制时的memory, 此进程就会被kubernetes杀掉

对于cpu和内存而言, pod的request和limit是指该pod中所有容器的 Requests或Limits的总和,

例如： 某个节点cpu资源充足, 而内存为4G，其中3GB可以运行pod, 而某个pod的memory request为1GB, limit为2GB， 那么这个节点上最多可以运行3个这样的pod

待调度pod的request值总和超过该节点提供的空闲资源, 不会调度到该节点node上;

一般 limits设置的值大于等于 request设置的值

resource.yaml

apiVersion: apps/v1 kind: Deployment metadata:  name: nginx-deployment spec:  selector:  matchLabels:  app: nginx  replicas: 1  template:  metadata:  labels:  app: nginx  spec:  containers:  - name: nginx  image: nginx:1.11  ports:  - containerPort: 80  resources:  limits:  cpu: 0.75 #750m=0.75c  memory: 500Mi #500MB=500Mi  requests:  cpu: 0.5  memory: 500Mi

 

重启策略（restartPolicy）

• Always：当容器终止退出后，总是重启容器，默认策略。

• OnFailure：当容器异常退出（退出状态码非0）时，才重启容器。

• Never：当容器终止退出，从不重启容器。

每个策略适用相应的场景，

never 适用定时任务，OnFailure 和 Always 适用一般应用程序，具体还是要根据业务性质来设置

 

apiVersion: v1 kind: Pod metadata:  name: foo  namespace: awesomeapps spec:  containers:  - name: foo  image: janedoe/awesomeapp:v1  restartPolicy: Always

健康检查（Probe）

 livenessProbe

如果检查失败，将杀死容器，根据Pod的restartPolicy来操作。

 readinessProbe

如果检查失败，Kubernetes会把Pod从service endpoints中剔除。 Probe支持以下三种检查方法：

 httpGet

发送HTTP请求，返回200-400范围状态码为成功。

 exec

执行Shell命令返回状态码是0为成功。

 tcpSocket

发起TCP Socket建立成功。

livenessProbe.yaml

apiVersion: v1 kind: Pod metadata:  labels:  test: liveness  name: liveness-exec spec:  containers:  - name: liveness  image: busybox  args:  - /bin/sh  - -c  - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60  livenessProbe:  exec:  command:  - cat  - /tmp/healthy  initialDelaySeconds: 5 #容器启动之后5s开始检查  periodSeconds: 5 #周期是5s  readinessProbe:  exec:  command:  - cat  - /tmp/healthy  initialDelaySeconds: 5  periodSeconds: 5

注意：这边未设置重启策略，一般缺省的默认策略是Always，镜像拉取策略 缺省的策略也是Always

健康检查失败，容器将会被重启，在k8s里没有重启一说，实际是删除容器重拉镜像重新起一个新的容器

查看pod已经重启了2次

 

 

pod调度策略

 

create pod ---》write apiserver ---》write etcd ---》scheduler ---》bind pod to node ---》write etcd ---》

kubelet(apiserver get pod) ---》docker api create container ---》apiserver ---》update pod status to etcd ---》kubectl get pods

 

 

• nodeName：

用于将Pod调度到指定的Node名称上

pod-nodename.yaml

apiVersion: v1 kind: Pod metadata:  name: pod-example2  labels:  app: nginx spec:  nodeName: k8s-node2  containers:  - name: nginx  image: nginx:1.15

• nodeSelector：

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

pod-nodeselector.yaml

 

apiVersion: v1 kind: Pod metadata:  name: pod-example2  labels:  app: nginx spec:  nodeSelector:  team: a  containers:  - name: nginx  image: nginx:1.15

查看 k8s-node1的默认lable

给k8s-node1 加一个 team=a的标签

kubectl label node k8s-node1 team=a

根据上面的yaml生成pod  符合预期，pod将会被调度到 label   为team=a 的 k8s-node1的节点上

说明：nodeSelector  相比 nodeName 组合更加灵活

nodeName不经过scheduler直接调度到指定节点，nodeSelector经过shceduler需要经过一些调度算法处理最后调度到相应节点。

如果都没指定这两种方式，则采用k8s默认的调度策略

污点与容忍

默认node节点都是没有打污点的，master节点是打上污点的。

 

应用场景：

• 节点独占

• 具有特殊硬件设备的节点

• 应对节点故障

kubectl taint node [node] key=value[effect]

其中[effect] 可取值：

NoSchedule ：一定不能被调度。

PreferNoSchedule：尽量不要调度。

NoExecute：不仅不会调度，还会驱逐Node上已有的Pod。

 

给k8s-node1打污点

kubectl taint node k8s-node1 abc=123:NoSchedule

打完污点后将之前根据pod-nodeselector.yaml 创建的 pod-example2  这个pod 删除，重新创建pod-example2

 

kubectl delete pod pod-example2 kubectl apply -f pod-nodeselector.yaml

查看pod 状态会发现一直是pedding状态

describe 查看发现 pod 没有可被调度的 node，这是符合预期的，因为指定了 含有lable  team=a的k8s-node1调度

然后 k8s-node1 被打了 污点，所以这时候 event 提示没有可被调度的节点

 

设置容忍

pod-nodetaint.yaml

apiVersion: v1 kind: Pod metadata:  name: pod-example2  labels:  app: nginx spec:  tolerations:  - key: "abc"  operator: "Equal"  value: "123"  effect: "NoSchedule"  nodeSelector:  team: a  containers:  - name: nginx  image: nginx:1.15

按照如上yaml设置容忍后 ，成功调度到k8s-node1

 

pod无法启动排查

kubectl describe TYPE/NAME kubectl logs TYPE/NAME [-c CONTAINER] kubectl exec POD [-c CONTAINER] -- COMMAND [args...]