4.k8s资源清单
一、资源类型
集群资源分类(适用性范围)
名称空间级别：kubeadm k8s kube-system （kubectl get pod -n default）默认是加default
集群级别：role
元数据型：HPA
K8s 中所有的内容都抽象为资源， 资源实例化之后， 叫做对象
- 名称空间
- 工作负载型资源(workload): pod , ReplicaSet, Deployment, StatefulSet,DaemonSet,Job,CronJob(ReplicationController在1.11版本被废弃)
- 服务发现及负载均衡型资源（ServiceDiscovery LoadBalance）:Service,Ingress,..
- 配置与存储型资源： Volume（存储卷），CSI（容器存储接口， 可以扩容各种各样的第三方存储卷）
- 特殊类型的存储卷： ConfigMap（当配置中心来使用的资源类型），Secret(保存敏感数据)，DownwardAPI(把外部环境中的信息输出给容器)
- 集群级别资源：
- Namespace，node，role ，clusterRole，RoleBinding，ClusterRoleBinding
- 元数据型资源：
- HPA(元数据)，PodTemplate（pod模板），LimitRange（资源限制）
二、YAML格式
pod定义yaml 文件说明
三、常用字段说明
Spec: 达到预期的状态
| 参数名 | 字段类型 | 说明 |
|---|---|---|
| version | String | 这里是值的是k8s API的版本， 目前基本上是v1， 可以用kubectl api-versions命令查询 |
| kind | String | 这里指的是yaml文件定义的资源类型和角色， 比如：Pod |
| metadata | Object | 元数据对象， 固定值就写metadata |
| metadata.name | String | 元数据对象的名字， 这里由我们编写，比如命名Pod的名字 |
| metadata.namespace | String | 元数据对象的命名空间， 由我们自身定义 |
| spec | Object | 详细定义对象， 固定值就写spec |
| spec.containers[] | list | 这里是spec对象的容器列表定义 ， 是一个列表 |
| spec.containers[].name | String | 这里定义容器的名字 |
| spec.containers[].image | String | 这里定义要用到的镜像名称 |
| spec.containers[].imagePullPolicy | String | 定义镜像拉取策略， 有Always，Never，IfNotPresent三个值（1）Always：意思是每次都尝试重新拉取镜像（2）Never：表示仅使用本地镜像（3）IfNotPresent：如果本地有镜像就使用本地镜像， 没有就拉取在线镜像，上面三个值都没有设置的话， 默认是Always |
| spec.containers[].command[] | List | 指定容器启动命令， 因为是数组可以指定多个，不指定则使用镜像打包时使用的启动命令 |
| spec.containers[].args[] | list | 指定容器启动命令参数， 因为是数组可以指定多个 |
| spec.containers[].workingDir | String | 指定容器的工作目录 |
| spec.containers[].volumeMounts[] | list | 指定容器内部的存储配置 |
| spec.containers[].volumeMounts[].name | String | 指定可以被容器挂载的存储卷的名称 |
| spec.containers[].volumeMounts[].mountPath | String | 指定可以被容器挂载的存储卷的路径 |
| spec.containers[].volumeMounts[].readOnly | String | 设置存储卷路径的读写模式， ture或者false，默认为读写模式 |
| spec.containers[].ports[] | list | 指定容器需要用到的端口列表 |
| spec.containers[].ports[].name | String | 指定端口名称 |
| spec.containers[].ports[].containerPort | String | 指定容器需要监听的端口号 |
| spec.containers[].ports[].hostPort | String | 指定容器所在主机需要监听的端口号， 默认跟上面containerPort相同， 注意设置了hostPort同一台主机无法启动该容器的相同副本（因为主机的端口号不能相同， 这样会冲突） |
| spec.containers[].ports[].protocol | String | 指定端口协议， 支持tcp和udp ， 默认值tcp |
| spec.containers[].env[] | List | 指定容器运行前需要设置的环境变量列表 |
| spec.containers[].env[].name | String | 指定环境变量名称 |
| spec.containers[].env[].value | String | 指定环境变量值 |
| spec.containers[].resources | Object | 指定资源限制和资源请求的值（这里开始就是设置容器的资源上限） |
| spec.containers[].resources.limits | Object | 指定设置容器的运行时资源的运行上限 |
| spec.containers[].resources.limits.cpu | String | 指定cpu的限制， 单位为core数， 将用于docker run --cpu-shares参数 |
| spec.containers[].resources.limits.memory | String | 指定MEM内存的限制， 单位为MIB,GiB |
| spec.containers[].resources.requests | Object | 指定容器启动和调度时的限制设置 |
| spec.containers[].resources.requets.cpu | string | CPU请求， 单位为core数，容器启动时初始化可用数量 |
| spec.containers[].resources.requets.memory | string | 内存请求， 单位为MIB，GiB， 容器启动的初始化可用数量 |
| Spec.restartPolicy | String | 定义Pod的重启策略， 可选值为Always，OnFailure，默认为Always，1.Always：Pod 一旦终止运行则无论容器是如何终止的， kubelet服务都将重启它，2，OnFailure： 只有Pod以非零退出码终止时 ， kubelet才会重启该容器， 如果容器正常结束（退出码为0），则kubelet将不会重启它， 3.Never：pod终止后，kubelet将退出码报告给Master，不会重启该pod |
| spec.nodeSelector | object | 定义node的label过滤标签， 以key：value格式指定 |
| spec.imagePullSecrets | object | 定义pull镜像时使用secret名称， 以name:secretkey格式指定 |
| spec.hostNetwork | Boolean | 定义是否使用主机网络模式， 默认为false， 设置true表示使用宿主机网络， 不使用docker网桥， 同时设置了true将无法再同一台宿主机上启动第二个副本 |
kubectl explain 可以查看详细的参数
例如看pod 的：kubectl explain pod
kubectl explain pod.spec
定义一个pod
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
version: v1
spec:
containers:
- name: app
image: hub.syuee.com/library/nginx:v1
- name: test
image: hub.syuee.com/library/nginx:v1
这里的两个容器都是使用的80端口， 所以会报错 ，下面排查报错
查看详细信息
kubectl describe pod myapp-pod
这里可以看到第二个容器报错
kubectl log myapp-pod -c test
从日志可以看到报错信息是80 端口被占用
四、pod生命周期
init c： 初始化容器（只是初始化，初始化完成后就会死掉，initc 不能并行）
pause： 初始化创建的时候initc 会连接到pause
mainc ：主容器（有多个）， 容器启动的时候会start操作， 当容器停止是会执行stop
liveness : 就绪检查，可以通过tcp检查， 通过进程检测 都通过了在改成ready
readiness : 生命周期检查（如容器里面的nginx进程卡死）当检测到进程卡死 ，我们可以执行重启或重建pod
pod生命周--》kube-》kubelet-》CRI-》pause-》init C-》main c （脚本和命名）（过程中有readiness和liveness参与）
五、initC
pod 能够具有多个容器， 应用运行在容器里面 ， 但是它也可能有一个或多个先于应用容器启动的Init容器
Init 容器与普通的容器非常像 ， 除了如下两点：
- Init 容器总是运行到成功完成为止
- 每个Init 容器都必须在下一个Init容器启动之前成功完成
如果Pod 的Init 容器失败， Kubernetes 会不断地重启Pod ， 直到Init 容器成功为止， 然而，如果Pod对应的restartPolicy为Never， 它不会重新启动
Init容器的作用
因为init容器具有应用程序容器分离的单独镜像， 所以它们的启动相关代码具有如下优势：
- 它们可以包含并运行实用工具， 但是出于安全考虑， 是不建议在应用程序容器镜像中包含这些实用工具的
- 它们可以包含实用工具和定制化代码来安装， 但是不能出现在应用程序镜像中，例如， 创建镜像没有必要FROM另一个镜像， 只需要在安装过程中使用类似sed ，awk， python或dig这样的工具
- 应用程序镜像可以分离出创建和部署角色， 二没有必要联合他们构建一个单独的镜像
- init容器使用linux namespace ， 所以相对应用程序容器来说具有不同的文件系统视图 ， 因此， 他们能够具有访问secret 的权限， 二应用程序容器则不能
- 他们必须在应用程序容器启动之前运行完成， 二应用程序容器是并行运行的。 所以inti容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法， 知道满足了一种先决条件
实例1: vim init-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox
command: ['sh','-c','echo The app is running! && sleep 3600']
initContainers:
- name: init-myservice
image: busybox
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for mysevice; slepp 2; done;']
- name: init-mydb
image: busybox
command: ['sh','-c','until nsloopup mydb; do echo waiting for mydb; sleep 2; done;']
kubectl describe pod myapp-pod # 查看myapp-pod 详情
kubectl log myapp-pod -c init-myservice # 查看初始化进程详情
这里可以看到解析不了myservice 和mydb
创建myservice.yaml
apiVersion: v1
kind: Service
metadata:
name: myservice
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9376
创建mydb
apiVersion: v1
kind: Service
metadata:
name: mydb
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9377
特殊说明
- 在Pod启动过程中， Init容器会按顺序在网络和数据卷初始化之后启动， 每个容器必须在一下容器启动之前成功退出
- 如果由于运行时或失败退出， 将导致容器启动失败， 它会根据Pod的restartPolicy 指定的策略进行重试 ， 然而， 如果Pod 的restartPolicy 设置为Always， Init容器失败时会使用RestartPolicy策略
- 在所有的Init 容器没有成功之前， Pod 将不会变成Ready状态， Init 容器的端口将不会在Service中进行聚集， 正在初始化中的Pod 处于Pending状态， 但应该会将Initializing状态设置为true
- 如果Pod 重启， 所有Init容器必须重新执行
- 对Init 容器spec 的修改被限制在容器image 字段， 修改其他字段都不会生效， 更改Init 容器的image字段， 等价于重启该Pod
六、探针
探针是由kubectl 对容器执行的定期诊断，要执行诊断 ， kubelet 调用由容器实现的Handler。 有三种类型的处理程序：
- ExecAction： 在容器内执行指定命令 。 如果命令退出时返回码为0 则认为诊断成功
- TCPSocketAction： 对指定端口上的容器的IP 地址进行TCP 检查。 如果端口打开。 则诊断被认为是成功的。
- HTTPGetAction： 对指定的端口和路径上的容器的IP 地址执行HTTP Get 请求。 如果响应的状态码大于等于200 ，且小于400 。 则诊断被认为是成功的
每次探测都将获得以下三种结果之一：
- 成功： 容器通过了诊断
- 失败： 容器未通过诊断
- 未知： 诊断失败 ， 因此不会采取任何行动
探测方式
livenessProbe： 指示容器是否正在运行 。 如果存货探测失败，则kubelet 会杀死容器， 并且容器将受到其重启策略的影响。 如果容器不提供存货探针， 则默认状态为Sussess
readinessProbe: 指示容器是否准备好服务请求， 如果就绪探测失败， 端点控制器将从与pod 匹配的所有Service的端点中删除该pod 的IP地址 ， 初始化延迟之前的就绪状态默认为Failure 。 如果容器不提供就绪探针。 则默认状态为Sussess 。
检测探针-就绪检测
readlinessProbe-httpget
Vim read.yaml
apiVersion: v1
kind: Pod
metadata:
name: readiness-httpget-pod
namespace: default
spec:
containers:
- name: readiness-httpget-container
image: nginx
imagePullPolicy: IfNotPresent
readinerssProbe:
httpGet:
port: 80
path: /index1.html #
initialDelaySeconds: 1 #延迟1秒
periodSeconds: 3 #过期3秒 就是3秒后重新检测
检测探针-存活检测
livenessProbe-exec
apiVersion: v1
kind: Pod
metadata:
name: liveness-exec-pod
namespace: default
spec:
containers:
- name: liveness-exec-container
image: hub.syuee.com/library/busybox
imagePullPolicy: IfNotPresent
command: ["/bin/sh","-c","touch /tmp/live ; sleep 60; rm -rf /tmp/live; sleep 3600"]
livenessProbe:
exec:
command: ["test", "-e", "/tmp/live"]
initialDelaySeconds: 1
periodSeconds: 3
livenessProbe-httpget
apiVersion: v1
kind: Pod
metadata:
name: liveness-httpget-pod
namespace: default
spec:
containers:
- name: liveness-httpget-container
image: hub.syuee.com/library/nginx:v1
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
livenessProbe:
httpGet:
port: http
path: /index.html
initialDelaySeconds: 1
periodSeconds: 3
timeoutSeconds: 10
livenessProbe-tcp
apiVersion: v1
kind: Pod
metadata:
name: probe-tcp
spec:
containers:
- name: nginx
image: hub.syuee.com/library/nginx:v1
livenessProbe:
initialDelaySeconds: 5
timeoutSeconds: 1
tcpSocket:
port: 80
periodSeconds: 3
多个检查合在一起
apiVersion: v1
kind: Pod
metadata:
name: probe-tcp
spec:
containers:
- name: nginx
image: hub.syuee.com/library/nginx:v1
ports:
- name: http
containerPort: 80
readinessProbe:
httpGet:
port: 80
path: /index1.html
initialDelaySeconds: 1
periodSeconds: 3
livenessProbe:
initialDelaySeconds: 5
timeoutSeconds: 1
tcpSocket:
port: 80
periodSeconds: 3
七、start、stop、相位
启动、退出动作
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-demo
spec:
containers:
- name: lifecycle-demo-container
image: nginx
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c","echo Hello form the postStart handler > /usr/share/message"]
proStop:
exec:
command: ["/usr/sbin/nginx", "-s", "quit"]
Pod phase 可能存在的值
挂起（Pending）: Pod 已被Kubernetes系统接受， 但有一个或者多个容器镜像尚未创建， 等待时间包括调度Pod 的时间和通过网络下载镜像的时间， 这可能需要花点时间
运行中（Running）：该Pod已经绑定到了一个节点上，Pod中所有的容器都已被创建， 至少有一个容器正在运行， 或者正处于启动或重启状态
成功（Succeeded): Pod中的所有容器都被成功终止， 并且不会在重启
失败（Failed）：Pod中所有容器都已终止了， 并且至少有一个容器是因为失败终止， 也就是说， 容器以非0状态退出或者被系统终止
未知（Unknown）：因为某些原因无法取得Pod的状态， 通常是因为与Pod所有主机通信失败
pod中只有一个容器并且正在运行， 容器成功退出
- 记录时间完成
- 如果restartPolicy为：
- Always: 重启容器， Pod phase任为Running
- OnFailure: Pod phase变成Succeeded
- Never: Pod phase变成Susseeded
Pod中只有一个容器并且正在运行。 容器退回失败
- 记录失败事件
- 如果restartPolicy为：
- Always： 重启容器， Pod phase仍为Running
- OnFailure：重启容器， Pod phase仍为Running
- Never： Pod phase变成Failed
Pod 中有两个容器并且正在运行。 容器退出失败
- 记录失败时间
- 如果restartPolicy
- Always： 重启容器； Pod phase 仍为Running
- OnFailure： 重启容器， Pod phase 仍为Running
- Never: 不重启容器； Pod phase 仍为Running
- 如果有容器1没有处于运行状态， 并且容器2 退出
- 记录失败事件
- 如果restartPolicy为：
- Always：重启容器； Pod phase 仍为Running
- OnFailure： 重启容器； Pod phase仍为Running
- Never： Pod phase 变成Failed
Pod 中只有一个容器并处于运行状态。 容器运行时内存超出限制
- 容器以失败状态终止
- 记录oom 事件
- 如果restartPolicy为：
- Always： 重启容器； Pod phase仍为Running
- OnFailure： 重启容器； Pod phase 仍为Running
- Never： 记录失败事件； Pod phase 仍为Failed
Pod 正在运行， 磁盘故障
- 杀掉所有容器。 记录适当事件
- Pod phase 编程Failed
- 如果使用控制器来运行， Pod 将在别处重建
Pod 正在运行， 其节点被分段
- 节点控制器等待直到超时
- 节点控制器将Pod phase 设置为Failed
- 如果是用控制器来运行， Pod 将在别处重建
