三、 pod详解
1、version: 版本号 kind: Pod
2、metadata: 元数据
* metadata.name: RFC规范的pod命名
* metadata.namespace: 所属的命名空间, 默认default.
* metadata.labels[ key-valus...]:自定义标签
* metadata.annotations: 自定义注解
3、Spec : Pod中容器定义
# spec.containers[ ] :容器列表
# spec.containers[ ].name :容器名称RFC 1035规范
# spec.containers[ ].image :容器的镜像名称
# spec.containers[ ].iamgePullPolicy :获取容器策略(always, never, ifNotPresent)
# spec.containers[ ].commond[] :启动命令列表,不指定则镜像打包时命令
# spec.containers[ ].args[] :启动时 命令参数列表
# spec.containers[ ].workingdir :工作目录
# spec.containers[ ].VolumeMounts :存储卷配置(共享名称、绝对路径、是否只读)
# spec.containers[ ].ports[] :暴露端口号列表(名称、容器port、主机port、协议TCP/udp)
# spec.containers[ ].env [] : 容器运行的环境变量列表 (名称、值)
# spec.containers[ ].resource :资源限制、请求的设置(limits限制设置CPU|Memory、请求设置CPU|memory)
# spec.columes[ ]: POD上容器共享存储卷列表 (存储卷名称、empty|hostPath|secret| configMap| )
# spec.columes[ ].livenessProbe : 容器内部健康检查,几次无响应后自动重启容器 (exec\httpGet\tcpSocket、检查间隔、超时设置),
# spec.restartPolicy:重启策略(always\OnFailure\newver)
# spec.nodeSelector :Pod将要调度的包含这些label的Node上。
# spec.imagePullSecrets:pull镜像时使用的secret名称。name:secretkey
# spec.hostNetWork:是否使用主机网络模式。True则使用主机网络,不再docker网桥,则该台主机无法启动第二个副本。
4、Pod基本用法:
- 创建额docker镜像以一个前台命令作为启动命令。(如果docker镜像运行完毕,容器自然关闭,而k8s的RC认为不正常关闭,则会无线循环重启)
使用supervisor辅助进行前台功能
- 由一个、多个容器封装组合而成。
5、静态pod. (由kubelet管理,仅在特定的node上的pod, 不能通过apiserver管理,无法健康检查)
* 创建方式: 配置文件、 http方式
* 配置文件方式,绝对路径path。启动参数配置 --config=${path},再重启kubelet服务, 会扫描到所有.yaml和.json进行创建。使用apiserver删除pod,则一直显示pending。只能到该节点删除.ymal文件。
* http方式: 略
6、pod共享卷配置(例: 一个Pod 包含tomcat、busybox)。
# 同一个Pod中多个容器共享Pod级别的存储卷Volume(tomcat写日志, busysbox读日志).
# 定义 : spec.volumnes: [{names: app-logs, emptyDir:{}}, ]
使用 : spec.containers[].volumeMounts: {name: app-logs, mountPath: /usr/local/tomcat/logs}
指定容器访问对应的log目录可看到相同
7、Pod的配置管理(应用程序和配置分离, 环境变量/外挂文件 来配置注入)
* 集群配置管理方案: ConfigMap (生成容器内的环境变量、设置容器启动命令参数、以Volume的形式挂载为容器内部文件目录)
* 使用key-value形式表示。value可以是值,也可以是文件。data: {datadir: /data/var, key-serverxml: <?xml><server>....</server>}
* 创建:
kubectl create configmap命令行方式创建ConfigMap。
kubectl create configmap Name --from-file=** --from-file=**** (从目录、文件创建)
--from-literal=key=value ... (从key-value赋值创建)
* 查看: kubectl get configmap / describe configmap ***
* 使用:
环境变量获取: env:[{name: *, valueFrom:{configMapKeyRef: {name: configmapName, key: key}}} , {....}] 。
Volume挂载: 例如将配置中的xml挂载到容器内 configfiles/new_name下。
容器内 ; volumeMounts: {name: c1, mountPath: /configfiles}
容器外配置Volumes: {name:c1,ConfigMap:{name: configmapname, items: {key: cmkey, path: new_name}}
*限制条件: Pod前创建、可以定义属于某个Namespace、不能配置管理、
APIserver管理的Pod可以使用,静态Pod不能使用CofigMap、
挂载的目录会覆盖原有其他文件,可以通过临时文件存储,然后在复制或者link。
8、Pod生命周期和重启
* Pending: Pod已创建,容器只有部分创建,或者在下载镜像。 Succeeded:成功执行退出、退出不重启。 Failed: 全部退出,但是至少一个失败。
Runing:全部创建,至少一个在运行(正常)、启动、重启(不正常)。 unknown:无法获取状态,可能网络不通畅。
* 重启策略(RestartPolicy) : always(默认) 、 OnFailure 、Never
always: 容器失效重启。 Onfailure: 终止运行退出、退出码不为0重启。
重启时间: 1、2、4、8,最长5min,成功重启后10min。重置重启时间
重启控制器:(ReplicationController | DaemondSet(always)、Job (Onfailure | never)、 kubelet管理 (失效重启))
9、Pod健康检查:LivenessProbe \ ReadinessProbe
# livenessProbe: 默认无值 success。 探测到不健康kubelet将其杀掉重启
# ReadinessProbe: 判断容器是否启动完成,如果检测 到失败,Pod状态被修改,EndPoint Controller将从service的EndPoint中删除容器的Pod.
# livenessProbe实现方式:
ExecAction:执行一个命令返回为0 ,泽健康。livenessProbe-exec-command: [cat, /tmp/health]
TCPSocketAction:通过IP和端口号TCP检查。libenessProbe-tcpSocket-port: 80
HTTPGetAction: 通过IP、端口号路径调用HTTP GET,状态码(200,400),则健康。livenessProbe-httpGet: {path: /_status/healthz, port: 80}
# 每种方式都有initialDelaySeconds(启动后首次检查等待时间)和timeoutSeconds(等待响应的超时时间/s)两个参数。
9、Pod调度。(容器的载体:RC、deployment、 daemonset、 job)完成 Pod的调度与自动化控制
> RC\Deployment: 【全自动调度】 : 内置的调度算法NodeSelector /NodeAffinity。Scheduler则会根据调度算法从Node中选择一个可用。
- .先给Node打标签。kubectl label nodes 《node_name》 < label-key>=<label-value>
- .Pod定义中加nodeSelector配置。 spec-selector-template-spec-[nodeSelector:{zone: north}, containers]
****NodeAffinity:亲和性调度 (包含NodeSelector的选择,也可设置亲和性策略)
- . RequiredDuringSchedulingRequiredDuringExecution:类似NdoeSelector, 不满足的Pod将从Node上移除,
- . RequiredDuringSchedulingIgoredDuringExecution:类似上个,不满足是不会移除之前调度的Pod。
- . PreferredDuringSchedulingIgnoredDuringExectuion:满足调度条件的Node,那些更具有优先,不满足Node条件,系统不一定移除之前的。
metadata-annotations-scheduler.alpha.kubenetes.io/affinity:{
"nodeAffinity" : {
"requiredDuringSchedulingIgnoreedDuringExecution": {
"nodeSelectorTerms": [
{ "matchExpressions": 【
{ "key":"kubernetes.io/e2e-az-name",
"operator":"in",
"value":["e2e-az1","e2e-az2"]
}】
} ,...............
]
}
}
}
operator : In 、NotIn、Exist、DoesNotExist、Gt、Lt。如果同时设置了NodeSelector和NodeAffinity,须同时满足才可以调度
> DaemonSet:【特定场景调度】(管理每个集群的Node上仅运行一个Pod副本的实例,例如:监控)
适宜场景: 每个Node上一个daemon进程,例如: GlusterFS存储或者Ceph存储
每个Node上运行一个日志采集程序, 例如: fluentd/logstach
每个Node上运行一份监控性能程序,例如: Prometheus, Exporter, collectd, New Relic agent, Ganglia gmond
> Job: 【 批处理调度】,kubernetes Job资源对象定义并启动一个批处理任务, 并行或者串行启动多个计算进程去处理一批工作项,直至完成结束
模式: Job Template Expansion (Job对象对应WorkItem) 、 Queue with pod Per Work Item(任务队列存放WorkItem, 启动N个POD) 、
Queue with Variable Pod Count(前者一样,启动Pod数量可变)
Single Job With Static Work Assignment模式,程序分配,而非队列
并行问题: Non-parallel Jobs(job Pod一一对应)、Parallel Josb with a fixed completion count(并行), Parallel jobs with a work queue(每个pod独立判断决定任务)
10、 Pod扩缩容(RC的scale机制)
* kubectl scale rc ***-rc --replicas=n;将 ***-rc扩缩容至n个
* k8sv1.1 Horizontal Pod Autoscaler( HPA):基于master的kube-controller-manager的餐胡--horizontal-pod-autoscaler-sync-perid,
周期性检测Pod的CPU使用率,满足定义阈值下,自动调节Pod数量。
> 需按照heapster组件
> 需在RC/Deployemnt中定义 resources.requests.cpu值,否则(hpa)无法正常工作
如 :一个RC xxx-rc中定义了resources.requests.cpu。kubectl autoscale rc php-apache --min=1 --max=10 --cpu-percent=50
11、Pod的滚动升级 (rolling-update): kubectl rooling-update创建一个新的RC 控制旧的RC中POD副本逐渐减少0, 同时新的RC中的副本从0 增加至目标值,
- 方法1:
* 创建新的版本v2,yaml文件。(RC名字不能与旧的相同,selector总至少一个Label与旧的不同,表示为新的RC)
* 运行命令: kubectl rolling-update name -f ***-v2.yaml
* 新的全部创建,旧的全部销毁
- 方法2:
* kubectl rooling-update name --image=redis-master:2.0
* 更新后与上个区别: 新的RC仍将使用该旧的名字