eg:
vim test.yaml
apiVersion: v1
kind: Pod
metadata: # pod 的源数据信息,可以写多个
name: nginx-busybox # pod 的名字
spec:
containers:
- name: nginx # 容器的名字
image: nginx:alpine # 镜像的名字
ports:
- containerPort: 80
- name: busybox
image: busybox
command: ["/bin/sh"]
args: ["-c", "while true; do echo hello; sleep 10;done"]
#创建pod
kubectl create -f test.yaml
#查看pod详细信息
kubectl describe pod nginx-busybox
静态pod
静态pod是由kubelet进行管理仅存在特定node上的pod。他不能通过API server进行管理,并且无法进行健康检查。创建方法:
- 配置文件方式
设置kubelet启动参数“--pod-manifest-path”或者在kubectl的配置文件中添加staticPodPath(官方推荐)
eg:--pod-manifest-path=/pods/kubelet
创建一个yaml文件,将其放入该目录中,kubelet会扫描该目录,创建目录下的pod。
使用docker ps命令可以查看到该容器,但是使用kubectl delete无法删除该pod,只能通过删除目录下的文件实现
- HTTP方式
设置启动参数“--manifest-url”,kubelet会定期从该url下载pod定义文件,可以解析yaml以及json文件。
configmap----pod的配置管理
典型用法:
- 生成容器内的环境变量
- 设置容器启动命令的启动参数
- 以volume的方式挂载为容器内部的目录或文件
config实现环境变量:
在1.6版本引入了envFrom,实现了pod环境中将configMap中所定义的字段自动转化为环境变量
#定义configMap
apiVersion: v1
kind: ConfigMap
metadate:
name: test-config
data:
a: 1
b: 2
#使用envFrom将config定义的变成环境变量
apiVersion: v1
kind: Pod
metadate:
name: env-config
spec:
- containers:
- name: env-config
image: busybox
command: ["/bin/bash", "-c" , "env"]
envFrom:
- configMapRef
name: test-config
创建pod后,容器内部的环境变量会添加a=1,b=2。当然,如果环境变量名非法时,系统会跳过该条继续执行。
configMap的限制条件:
- 必须在pod之前创建
- 不能跨namespace使用
- 无法实现配额管理
- 静态pod无法使用configMap
- 只能挂载目录,无法挂载文件。同时,被挂载的容器内部的目录将被覆盖
Downward API
作用:让 Pod 里的容器能够直接获取到这个 Pod API 对象本身的信息。
实现方法:
pod的生命周期
- 挂起(Pending):Pod 已被 Kubernetes 系统接受,但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间,这可能需要花点时间。
- 运行中(Running):该 Pod 已经绑定到了一个节点上,Pod 中所有的容器都已被创建。至少有一个容器正在运行,或者正处于启动或重启状态。
- 成功(Succeeded):Pod 中的所有容器都被成功终止,并且不会再重启。
- 失败(Failed):Pod 中的所有容器都已终止了,并且至少有一个容器是因为失败终止。也就是说,容器以非0状态退出或者被系统终止。
- 未知(Unknown):因为某些原因无法取得 Pod 的状态,通常是因为与 Pod 所在主机通信失败。
pod的健康检查
探针由kubelet检测容器执行的定期诊断。要执行诊断,kubelet 调用由容器实现的Handler。有三种类型的处理程序:
- ExecAction:在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
- TCPSocketAction:对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开,则诊断被认为是成功的。
- HTTPGetAction:对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400,则诊断被认为是成功的。
每次探测都将获得以下三种结果之一:
成功:容器通过了诊断。
失败:容器未通过诊断。
未知:诊断失败,因此不会采取任何行动。
livenessProbe
:指示容器是否正在运行。如果存活探测失败,则 kubelet 会杀死容器,并且容器将受到其 重启策略 的影响。如果容器不提供存活探针,则默认状态为Success
。readinessProbe
:指示容器是否准备好服务请求。如果就绪探测失败,端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为Failure
。如果容器不提供就绪探针,则默认状态为Success
。
pod调度
Deployment或RC(全自动调度)
NodeSelector(node定向调度)
通过node上的标签实现的
eg:
kubectl lable nodes k8s-node1 disktype=ssd #添加标签
kubectl get nodes --show-labels #查看标签
#定义pod
apiVersion: v1
kind: Pod
metadata:
name: nginx-namespace
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 8
nodeSelector:
disktype: ssd
NodeAffinity(node亲和度调度)
当前有两种类型的节点关联性,称为requiredDuringSchedulingIgnoredDuringExecution和 preferredDuringSchedulingIgnoredDuringExecution。您可以将它们分别视为“硬”和“软”,在某种意义上,前者指定了将Pod调度到节点上必须满足的规则(就像 nodeSelector但使用更具表现力的语法一样)指定调度程序将尝试强制执行但不能保证的首选项。后者的与要求时尽量达到的选项
名称的“ IgnoredDuringExecution”部分意味着,与nodeSelector工作原理类似,如果节点上的标签在运行时发生更改,从而不再满足Pod上的相似性规则,那么Pod仍将继续在该节点上运行。
apiVersion: v1
kind: Pod
metadata:
name: with-node-affinity
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/e2e-az-name
operator: In
values:
- e2e-az1
- e2e-az2
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: another-node-label-key
operator: In
values:
- another-node-label-value
containers:
- name: with-node-affinity
image: k8s.gcr.io/pause:2.0
NodeAffinity语法支持的操作符有:in,notin,exists,doesnotexist,gt,lt。因此,可以通过notin、doesnotexist实现node的排斥功能
使用规则:
- 如果同时指定nodeSelector和nodeAffinity,则必须满足两个条件,才能将Pod调度到候选节点上。
- 如果指定了多个nodeSelectorTerms关联nodeAffinity类型,那么只需要其中有一个能匹配即可
- 如果您指定matchExpressions与关联的多个nodeSelectorTerms,那么只有 matchExpressions在满足所有条件的情况下才能运行该pod