k8s-04-资源清单

资源介绍
资源掌握资源清单的语法编写 Pod 掌握 Pod 的生命周期***
在这里插入图片描述
名称空间级别

-n 指定命名空间（默认命名空间 -n default）；k8s系统组建放在kube-system 空间下

工作负载型资源（workload）:pod 、ReplicaSet、Deployment、StatefulSet、DaemonSet、Job、CronJob、ReplicationController(1.11版本中被废弃)
服务发现及负载均衡型资源（ServiceDiscovery LoadBalance）:Service、Ingress…
配置与存储型资源：Volume(存储卷)、CSI(容器存储接口，可以扩展成各种各样的第三方存储接口)
特殊类型的存储卷：ConfigMap（当配置中心来使用的资源类型）Sercet(保存敏感数据)、DownwardAPI(把外部环境的信息输出给容器)

集群级别
Namespace、Node、Role、ClusterRole、RoleBinding、ClusterRoleBinding

元数据型
HPA、PodTemplate、LimitRange
常用字段的解释

在这里插入图片描述
其他参数

spec.containers[].name (String): 定义容器的名字
spec.containers[].image (String): 走义要用到的镜虑名称
spec.containers[].imagePullPolicy (String):
定义镜像拉取策，有Always、Never、IfNotPresent 三个值可选（默认值是Always）
(1)Always:是每次都尝试重新拉取镜像
(2)Never:表示仅便用本地镜
(3)IfNOtPresent：如果本地有镜像就使用本地镜像，没有就拉取在线镜像。
spec.containers[].command[] (List):
指定容器启动命令，因为是数组可以指定多个，不指定则使用镜像打包时使用的启动命令。
spec.containers[].largs[] (List):
指定容器启动命令参数，因为是数组可以指定多个。
spec.containers[].worKingDir (String): 指定容器工作目录
spec.containers[].volumeMounts[] (List): 指容器内部的存卷配置
spec.containers[].volumeMounts[].name (String):
指可以被容器挂载的存储卷的名称
spec.containers[].volumeMounts[].mountPatn (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参数（这里前面文章Pod资源限制有讲过）
spec.containers[].resources.limits.memory (String):
指定MEM内存的限制，单位为MiB、GiB
spec.restartPolicy (String): 定义Pod的重启策略, 默认值为 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.imagePuIlSecrets (Object): 定义pull镜像时便用secret名称，以name:secretkey格式指定
spec.hostNetwork (Boolean): 定义是否使用主机网络模式，默认值为false。设置true表示使用宿主机网络，不使用docker网桥，同时设置了 true将无法在同一台宿主机上启动第二个副本。

资源清单格式（kubectl explain pod）
在这里插入图片描述
资源清单定义pod

# 清单模版  vim pod-demo.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-demo
  namespace: default
  labels:
    app: myapp
spec:
  containers:
  - name: busybox-1
    image: busybox:latest
    command: 
    - "/bin/sh"
    - "-c"
    - "sleep 1000"
 # 创建
 kubectl apply -f pod-demo.yaml 
 # 查看   
 kubectl get pod
 #

容器声明周期
在这里插入图片描述
Pod 能够具有多个容器，应用运行在容器里面，但是它也可能有一个或多个先于应用容器启动的 Init 容器，Init 容器与普通的容器非常像，除了如下两点：

Init 容器总是运行到成功完成为止
每个 Init 容器都必须在下一个 Init 容器启动之前成功完成

如果 Pod 的 Init 容器失败， Kubernetes 会不断重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的 restartPolicy 为 Never，它不会重新启动。
因为 Init 容器具有与应用程序容器分离的单独镜像，所以它们的启动相关代码具有如下优势：

它们可以包含并运行实用工具，但是出于安全考虑，是不建议在应用程序容器镜像中包含这些实用工具的
它们可以包含使用工具和定制化代码来安装，但是不能出现在应用程序镜像中。例如，创建镜像没要 FROM 另一个镜像，只需要在安装过程中使用类似sed、awk、python 或 dig 这样的工具。
应用程序镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像。
Init 容器使用 Linux Namespace，所以相对应用程序容器来说具有不同的文件系统视图。因此，它们能够具有访问 Secret 的权限，而应用程序容器则不能。
它们须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以 Init 容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法，直到满足了一组先决条件。

特殊说明

在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
Init 容器具有应用容器的所有字段。除了 readinessProbe，因为 Init 容器无法定义不同于完成 (completion) 的就绪（readiness）之外的其他状态。这会在验证过程中强制执行
在 Pod 中的每个 app 和 Init 容器的名称必须唯一; 与枉何其它容器共享同一个名称，会在验证时抛出错误

init容器（实验）

 创建资源模版  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 runing! && sleep 3600']
  initContainers:
 - name: init-myservice
    image: busybox
    command: ['sh', '-c', 'until nslookup myservice; do echo waithing for myservice; sleep 2; done;']
 - name: init-mydb
    image: busybox
    command: ['sh', '-c', 'until nslookup mydb; do echo waithing for mydb; sleep 2; done;']
# 根据模版创建容器
kubectl create -f init-pod.yaml
# 查看容器 （初始化容器有2个 没有一个init）,主容器没有read
[root@k8s ~]# kubectl get pod
NAME        READY   STATUS     RESTARTS   AGE
myapp-pod   0/1     Init:0/2   0          2m37s
# 创建一个init容器 im myservice.yaml
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
#创建init容器
kubectl apply -f myservice.yaml
# （初始化容器有2个 一个init）,主容器没有read
[root@k8s ~]# kubectl get pod
NAME        READY   STATUS     RESTARTS   AGE
myapp-pod   0/1     Init:1/2   0          7m32s
# 创建一个init容器 vim mydb.yaml
# 说明：因为init容器是顺序执行（必须在上一个退出之后执行，所以端口可以相同）
apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9377
# 创建容器      
#kubectl apply -f mydb.yaml
# 2个初始化容器 都创建了，主容器也ready
# kubectl get pod
NAME        READY   STATUS    RESTARTS   AGE
myapp-pod   1/1     Running   0          12m

容器探针
探针是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet调用由容器实现的 Handler。有三种类型的处理程序：

ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断
被认为是成功的。
HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的
状态码大于等于 200 且小于 400，则诊断被认为是成功的

每次探测都将获得以下三种结果之一：

成功：容器通过了诊断。
失败：容器未通过诊断。
未知：诊断失败，因此不会采取任何行动

探测模式
livenessProbe: 指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为 Success
readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。

就绪检测（实验）[readinessProbe]

#vim readiness-probe-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
  name: readiness-httpget-pod
  namespace: default
spec:
  containers:
  - name: readiness-httpget-pod
    image: nginx
    imagePullPolicy: IfNotPresent
    readinessProbe:
      httpGet:
        port: 80
        path: /index1.html
      initialDelaySeconds: 1
      periodSeconds: 3
kubectl apply -f readiness-probe-httpget.yaml
# 因为没有 indes1.html 文件，pod 无法进入 ready 状态
[root@k8s ~]# kubectl get pod
NAME                    READY   STATUS    RESTARTS   AGE
readiness-httpget-pod   0/1     Running   0          69s
# 创建 index1.html 文件
kubectl exec readiness-httpget-pod -it -- /bin/sh
cd /usr/share/nginx/html/
echo "readiness" > index1.html
exit
# 有 indes1.html 文件，pod进入 ready 状态
[root@k8s ~]# kubectl get pod
NAME                    READY   STATUS    RESTARTS   AGE
readiness-httpget-pod   1/1     Running   0          3m30

存活检测（实验）
liveness-exec-pod 探测模式【livenessProbe -exec】

# vim liveness-exec.yaml

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec-pod
  namespace: default
spec:
  containers:
  - name: liveness-exec-container
    image: busybox
    imagePullPolicy: IfNotPresent
    command: ["/bin/sh","-c","touch /tmp/live ; sleep 60; rm -rf /tmp/live; sleep 600"]
    livenessProbe:
      exec:
        command: ["test","-e","/tmp/live"]
      initialDelaySeconds: 1
      periodSeconds: 3
# kubectl apply -f liveness-exec.yaml
# 文件创建600后被删除，所以没有存活
# kubectl get pod -w

liveness-httpget-pod 探测模式【livenessProbe -httpGet】

# vim liveness-probe-httpget.yaml 

apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget-pod
  namespace: default
spec:
  containers:
  - name: liveness-httpget-pod
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80     
    livenessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10
   # kubectl apply -f liveness-probe-httpget.yaml
   # 查看服务正常运行
   # kubectl get  pod

liveness-probe-tcp 探测模式【livenessProbe -tcpSocket 】

# vim liveness-probe-tcp.yaml

apiVersion: v1
kind: Pod
metadata:
  name: liveness-probe-tcp
spec:
  containers:
  - name: liveness-probe-pod
    image: nginx
    livenessProbe:
      initialDelaySeconds: 1
      timeoutSeconds: 1
      tcpSocket:
        port: 80

#kubectl apply -f liveness-probe-tcp.yaml
# 查看服务正常运行
#kubectl get pod

启动退出动作【lifecycle-postStart/preStop】

cat lifecycle-demo.yaml 
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 Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/bin/sh","-c","echo Hello Hello from the postStop handler > /usr/share/message"]

kubectl apply -f lifecycle-demo.yaml 
# 进入容器内
kubectl exec -it lifecycle-demo -- /bin/sh
# 查看输出结果
# cat /usr/share/message

Pod phase 可能存在的值

挂起(Pending）：Pod 己被Kubernetes系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod
的时间和通过网络下载镜像的时间，这可能需要花点时间
运行中(Running）：该Pod己经绑定到了一个节点上，Pod中所有的容器都己被创建。至少有一个容
器正在运行，或者正处于启动或重启状态
成功（Succeeded）：Pod中的所有容器都被成功终止，并且不会再重启
失败(Failed)：Pod中的所有容器都己终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止
未知(Unknown)：因为某些原因无法取得Pod的状态，通常是因为与Pod所在主机通信失败

猜你喜欢