POD
Pod基本概念
- 最小的部署单元
- 一个Pod中的容器共享网络命名空间
- Pod是短暂的
Pod存在的意义
Pod为亲密性应用而存在
应用场景
- 两个应用之间发生文件交互
- 两个应用之间需要通过127.0.0.1或者socket通讯
- 两个应用需要发生频繁的调用
Pod的实现机制与设计模式
-
共享网络
启动每个容器后都会生成一个对应pause容器,来存放容器的命名空间和IP
-
共享存储
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 mountPant: /data -name: read image: centos command: ["bash","-c","tail -f /data/hello"] volumeMounts: - name: data mountPath: /data volumes: - name: data emptyDir: {}
容器类型
-
Infrastructure Container
基础容器: 维护整个pod网络空间
-
Initcontainers
初始化容器: 限于业务容器开始运行
-
Containers
业务容器: 并行启动
Pod镜像
拉取镜像策略
-
yaml文件键值: imagePullPolicy
-
IfNotPresent
默认值: 镜像在宿主机上不存在时才拉取
-
Always
每次创建Pod都会重新拉取一次镜像
-
Never
Pod永远不会主动拉取这个镜像
更新镜像两种方法
## 1. 命令行
kubectl set image
## 2. 修改yaml文件的tag,然后apply
拉取镜像认证
kubectl配置
kubectl create secret docker-registry my-regsecret --docker-server=registry-vpc.cn-hangzhou.aliyuncs.com --docker-username=admin --docker-password=123456 --docker-email=xxxx@qq.com
yaml配置
spec:
containers:
- name: foo
image: janedoe/awesomeapp:v1
imagePullPolicy: my-regsecret
资源限制
-
Pod和Container的资源请求和限制
spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory
limit: 实际最大使用的配额
requests: 申请配额,主要用于K8S做资源调度分配时参考值
单位: 1000m=1个cpu,500m=0.5c,250m=0.25c
yaml写法
apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
containers:
- name: db
image: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: "password"
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
- name: wp
image: wordpress
resources:
requests:
memory: "64Mi"
cpu: "250m"
limit:
memory: "128Mi"
cpu: "500m"
重启机制
-
Always: 当容器停止,总是重建容器,默认策略
守护进程模式: 例如nginx,mysql,redis
-
OnFailure: 当容器异常退出(退出状态码非0)时,才重启容器
-
Never: 当容器终止退出,从不重启容器
预期终止:
pod健康检查
Probe机制,有两种类型
-
livenessProbe(存活检查)
如果检查失败,将杀死容器,根据pod的restartPolicy操作
-
readinessProbe(就绪检查)
如果检查失败,Kubenetes会把pod从service endpoints中删除
Probe支持以下三种检查方法
-
httpGet
发送HTTP请求,返回200-400范围状态码为成功
-
exec
执行shell命令返回状态码为0为成功,例如: [ -e pidfile ] && echo 0 || echo 1
-
tcpSocket
发起TCP Socket建立成功
POD调度流程
调度策略
-
nodeName
Pod.spec.nodeName 强制约束pod调度到指定的node节点
-
nodeSelector
Pod.spec.nodeSelector 通过lable-selector机制选择节点
打标签命令:
kubectl label nodes k8s-node1 team=web01 kubectl get node --show-labels
yaml文件
apiVersion: v1 kind: Pod metadata: name: pod-example labels: app: nginx spec: #nodeName: k8s-node2 nodeSelector: team: "web01" containers: - name: nginx image: nginx:latest
-
污点与容忍
节点独占
具有特殊硬件设备的节点
污点设置:
kubectl taint node [node] key=value[effect] kubectl taint node [node] app=nginx:NoSchedule kubectl describe node |grep Taint
其中[effect]可取值:
NoSchedule: 一定不能被调度
PreferNoSchedule: 尽量不要被调度
NoExecute: 不仅不会调度,还会驱逐Node上已有的Pod
去掉污点:
kubectl taint node [node] key:[effict]- kubectl taint node [node] app=nginx-
容忍污点:
spec: tolerations: - key: "app" operator: "Equal" value: "nginx" effect: "NoSchedule" containers: - name: pod-tains image: busybox:latest
POD启动流程
kubectl–> create pod–>apiserver–>etcd
schedule–>apiserver–>bind pod to node
kubelet–>apiserver–>bound self pod–>docker run container–>apiserver update pod status
POD故障排查
- kubectl describe TYPE/NAME
- kubectl logs TYPE/NAME [-c CONTAINER]
- kubectl exec POD [-c CONTAINER] --COMMAND [args…]
POD-YAML配置文件
示例: busybox.yaml
apiVersion: v1
kind: Pod
metadata:
name: busybox
namespace: default
labels:
app: busybox
spec:
containers:
- name: busybox
image: busybox
ports:
command:
- ping
- "www.baidu.com"
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
restartPolicy: Always
示例: nginx.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
namespace: web
# 标签
labels:
app: nginx
spec:
# 节点绑定
# nodeNmae: node01
nodeSelector:
env_role: dev
containers:
- name: nginx
image: nginx
ports:
- protocol: TCP
containerPort: 80
# 资源限制
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
restartPolicy: OnFailure