欢迎访问我的博客,你的支持,是我最大的动力!

马哥_K8s进阶实战(2)管理Pod资源对象

Linux 小马奔腾 525℃ 评论
目录:
[显示]

管理Pod资源对象

使用容器标准方式:一个容器仅运行一个进程,日志信息直接输出至容器的标准输出(kubectl logs查看日志)

为Pod对象中各容器提供网络名称空间等共享机制的是底层基础容器 pause

多容器Pod模型:Sidecar pattern 边车模型或跨斗模型、Ambassador pattern 大使模型、Adapter pattern 适配器模型

管理Pod对象容器

资源清单项目:容器名称、镜像、要暴露的端口、改变镜像运行程序、传递环境变量、资源配额等

镜像获取

镜像获取策略 imagePullPolicy:
Always 当镜像标签为 latest 或不存在时,总是从指定仓库中获取镜像
IfNotPresent 仅当本地镜像缺失时才下载
Never 禁止从仓库下载  仅使用本地镜像

标签为 latest 的镜像,默认策略为 Always ; 其他标签的镜像,默认策略为 IfNotPresent

端口暴露

因为所有容器网络在同一网络平面,故任何监听在非lo接口上的端口都可以被其他Pod访问,显示指定容器端口,只是信息性数据,还可赋予名称方便调用
# kubectl explain pods.spec.containers.ports
containerPort 必填
name 端口名称 可被service资源调用
protocol TCP/UDP 默认TCP

若需要经由Pod对象所有节点NAT,可配置hostPort(0-65536) hostIP(默认 0.0.0.0)

运行程序

Dockerfile中ENTRYPOINT定义应用程序,CMD定义传递给程序的参数。若ENTRYPOINT不存在,CMD可同时指定程序和参数
docker inspect ikubernetes/myapp:v1 -f {{.Config.Cmd}}
[nginx -g daemon off;]
docker inspect ikubernetes/myapp:v1 -f {{.Config.Entrypoint}}
[]
可覆盖镜像中默认的程序和参数
若仅定义args字段,它将作为参数传递给镜像中默认指定运行的应用程序
若仅定义command字段,将覆盖镜像中定义的程序和参数,以无参方式运行应用程序

环境变量

应用程序若不支持从环境变量获取配置,可通过 entrypoint 脚本完成环境变量到程序配置文件的同步

向Pod对象中容器传递环境变量有两种方法:env 和 envFrom

引用方法 $(VAR_NAME)

共享节点的网络名称空间

以kubeadm部署的集群中kube-apiserver、kube-controller-manager、kube-scheduler、kube-proxy、kube-flannel通常为第二种类型
仅需设置 spec.hostNetwork 为 true 即可创建第二种共享节点网络名称空间的Pod

kubectl exec -it kube-proxy-cm624 -n kube-system -- sh
ip a
kubectl exec -it curl-66959f6557-ckq47 -- sh
ifconfig  或 ip a

设置Pod对象安全上下文

设定Pod或容器的权限和访问控制
Pod级别为 spec.securityContext 容器级别为spec.containers[].securityContext

busybox容器,以uid1000的非特权用户运行容器并禁止权限升级

kubectl apply -f pod-with-securitycontext.yaml
kubectl exec pod-with-securitycontext -- ps aux

标签和标签选择器

Label/Label Selector 键值对

键前缀/键名:键值 如 kubernetes.io/mykey:myvalue
键前缀必须为DNS子域名格式,可省略

标签 Label

资源标签 labels 位于 metadata

# 查看标签
kubectl get pods --show-labels
kubectl get deployments.apps --show-labels
# 显示特定键的标签信息 -L key1,key2,...
kubectl get pods -L pod-template-hash,run
# 添加标签 --overwrite 修改已有标签
kubectl label pods/pod-with-securitycontext run=haha

标签选择器 Label Selector

基于等值关系,env=production env!=qa
基于集合关系,tier in (frontend,backend)
原则:
同时指定的多个选择器是 AND 与 操作
使用空值标签,表示选择全部
空的标签选择器,表示没有资源被选择

# 使用标签选择器 -l
kubectl get pods -l run=nginx-deploy
kubectl get pods -l run!=nginx-deploy
kubectl get pods -l run==nginx-deploy
kubectl get pods -l run=nginx-deploy,name=ma   # 多个选择器
kubectl get pods -l "run=nginx-deploy,name=ma"  # 可添加引号

基于集合关系的选择器:
key in (val1,val2,...)    在集合中即可
key notin (val1,val2,...)   不在集合中
key  所有存在此键名标签的资源
!key 所有不存在此键名标签的资源

kubectl get pods -l "run in (nginx-deploy,aa)"
kubectl get pods -l '!run'    # 为避免shell解析!必须使用单引号
kubectl get pods -l 'run in (nginx-deploy),!name'

Service/Deployment/ReplicaSet等关联到Pod对象
通过在spec字段嵌套selector字段,通过matchLabels指定标签选择器

matchLabels 直接用键值对
matchExpressions 基于表达式指定标签选择器列表

Pod 节点选择器 nodeSelector

让Pod在选定节点上运行,实现节点亲和性调度,spec.nodeSelector
绑定到特定节点还有一种方法 使用 spec.nodeName

kubectl get nodes --show-labels
kubectl label nodes kube-node1 disktype=ssd  # 为节点添加标签
kubectl get nodes -L disktype

资源注解

查看资源注解
kubectl get -o yaml 和 kubectl describe 命令可显示资源注解信息
kubectl get pods pod-example -o yaml
kubectl describe pods pod-example

创建资源时 metadata.annotations进行指定,也可按需添加
kubectl annotate pods pod-example ma=dong  # 添加注解
注解值可为中文

Pod对象的生命周期

Pod的相位:
Pending,创建了Pod资源对象并已存入etcd中,但尚未被调度完成
Running,已被kubelet创建完成
Succeeded,Pod中所有容器都已成功终止并不会被重启
Failed,所有容器都已终止,但至少有一个容器终止失败,即容器返回非0退出状态或已被系统终止
Unknown,无法获取Pod状态信息

Pod生命周期中重要行为

1、初始化容器 init container
主容器启动之前要运行的容器,常用于执行一些预置操作
初始化容器必须运行完成至结束,每个初始化容器都必须按定义顺序串行运行
运用:
spec.initContainers 定义,类似于 spec.containers

2、生命周期钩子函数 lifecycle hook
位于kubectl explain pods.spec.containers.lifecycle.postStart.exec
postStart,容器创建完成后立即运行,不保证一定会于容器中ENTRYPOINT之前运行
preStop,容器终止操作之前立即运行,在其完成前会阻塞删除容器的操作调用
钩子处理器实现方式:Exec 和 HTTP
Exec,在钩子事件触发时,直接在当前容器中运行由用户定义的命令
HTTP,在当前容器中向某Url发起HTTP请求

kubectl exec lifecycle-demo -- cat /usr/share/nginx/html/test.html

3、容器探测 container probe
kubelet对容器周期性的健康状态诊断
pods.spec.containers.livenessProbe
pods.spec.containers.readinessProbe
ExecAction,在容器内执行命令,检测状态码是否为0
TCPSocketAction,与容器的某tcp端口尝试连接,端口打开即为正常
HTTPGetAction,向容器某端口发起get请求,响应码为2xx 3xx即为正常
kubelet可以活动容器上执行两种检测
存活性检测 livenessProbe,判定容器是否为Running状态,不通过则杀死容器,未定义存活性检测默认为 Success
就绪性检测 readinessProbe,判断容器是否就绪并可对外提供服务,不通过则不会添加到Service对象端点列表中

容器重启策略

pods.spec.restartPolicy
Always,默认,总是重启
OnFailure,出错时重启
Never,不重启
反复重启的延迟时间:10、20、40、80、160、300秒逐次延长,最大300秒

Pod 终止过程

系统强制删除操作宽限期倒计时(30s)启动,发送TERM信号到Pod中每个容器的主进程,倒计时结束,发送KILL信号
--grace-period=<seconds> 自定义宽限期时长,默认30秒

Pod 存活性探测

三种推测方法:ExecAction、TCPSocketAction、HTTPGetAction

exec 探针

spec.containers.livenessProbe.exec 仅有一个属性 command
exec运行于容器中,会消耗容器可用资源,探测命令应尽可能简单和轻量

shell命令
test -e /root/a.yaml    # 若在在则返回0 不存在返回1

kubectl describe pods liveness-exec
Last State: Terminated
Exit Code: 137   # 128+signum   signum是导致进程终止的信号的数字标识 9 -> SIGKILL

HTTP 探针

spec.containers.livenessProbe.httpGet 向目标空器发起http请求,根据响应码判断
host <string> 默认为Pod IP,也可在httpHeaders中使用Host:定义
port <string> 必填
httpHeaders <[]Object> 请求头
path <string> 路径,url
scheme 默认为HTTP,也可是HTTPS

kubectl exec liveness-http -- rm /usr/share/nginx/html/healthz # 删除测试页面

TCP 探针

spec.containers.livenessProbe.tcpSocket 检查容器指定端口是否开启,相比http更高效、更省资源,但精度略低
host 默认为Pod IP
port 必选

Liveness: http-get http://:http/healthz delay=0s timeout=1s period=10s #success=1 #failure=3
其中的delay=0s timeout=1s period=10s #success=1 #failure=3 由spec.containers.livenessProbe下属性字段指定
initialDelaySeconds ,探测延迟,默认为0s 容器启动后立即开始探测
timeoutSeconds ,超时,默认值1s,最小值也为1s
periodSeconds,频率,默认10s
successThreshold,处于失败状态时,连接多少次成功才被认为是成功,默认1
failureThreshold,处于成功状态时,连接多少次失败被认为是失败,默认3

Pod 就绪性探测

spec.containers.readinessProbe

就绪性检测 readinessProbe,判断容器是否就绪并可对外提供服务,不通过则不会添加到Service对象端点列表中
检测周期默认为10s

未定义就绪性探测的Pod进入Running状态后立即就绪

资源需求及限制

requests 确保可用的最小资源,不一定会用得到,可能会用不到
limits 最大值,硬限制

对于压缩型资源cpu来说,在未定义requests时,它可能被其他pod资源压缩至极低的水平,甚至达到不能被调度运行的境地
对于非压缩资源mem来说,内存资源在任何原因导致的紧缺情形下都可能导致相关进程被杀
k8s调度器会根据容器的requests中定义的用量判断节点是否满足需求
对一个节点来说,每运行一个Pod对象,其requests中定义的请求量都要被预留,直到被所有Pod对象用完为止
若容器请求超过limits的内存资源时,会被OOM杀死,而后根据重启策略重启 OOMKilled

一个cpu逻辑核心为 1 core = 1000 millicores 即1000m
内存单位为 G Gi M Mi K Ki 默认为字节

kubectl exec stress-pod -- top
kubectl get pods -w     # -w watch 查看数据变化

limits的值不作为调度的依据,即可资源超配

容器的可见资源

容器可见资源量是节点级别的可用总量
若要将limits定义的资源量暴露给容器,可以使用Downward API

Pod服务质量

确定在必须终止部分Pod时,终止Pod的次序
Guaranteed,最高优先级,requests和limits属性相等
Burstable,中等优先级,至少一个容器设置了cpu或mem的requests属性
BestEffort,最低优先级,未设置requests或limits属性
当资源紧缺时,BestEffort类别的容器优先被终止
同等级时,内存占用比例最大的Pod优先被终止

 

转载请注明:轻风博客 » 马哥_K8s进阶实战(2)管理Pod资源对象

喜欢 (0)or分享 (0)