四、K8S-资源清单

K8S中存在哪些资源

---

什么是资源？

K8S中所有的内容都抽象为资源，资源实例化之后叫做对象

集群资源分类（根据实用性范围分类）

• 名称空间级别

  • 工作负载型资源：Pod、ReplicaSet、Deployment、StatefulSet、DaemonSet、Job、CronJob
  • 服务发现及负载均衡型资源：Service、Ingress
  • 配置与存储资源：Volume（存储卷）、CSI(容器存储接口，可以扩展各种各样的第三方存储卷## 标题)
  • 特殊类型的存储卷：ConfigMap（当配置中心来使用的资源类型）、Secret（保存敏感数据）、DownwardAPI（把外部环境中的信息输出给容器）

• 集群级别

  • Namespace
  • Node
  • Role
  • ClusterRole
  • RoleBinding
  • ClusterRoleBinding

• 元数据型

  • HPA
  • PodTemplate
  • LimitRange

Yaml格式

---

在K8S中，一般使用yaml格式的文件来创建符合我们与其期望的pod，这样的yaml文件我们一般称为资源清单

简单说明

是一个可读性高，用来表达数据序列的格式，YAML的意思其实是：仍是一种标记语言，单位了强调这种语言以数据为中心，而不是以标记语言为重点

基本语法

• 缩进时不允许使用Tab键，只允许使用空格
• 缩进的空格数目不重要，只要相同层级的元素左侧对齐即可
• #标识注释，从这个字符一直到行尾，都会被解释器忽略

YAML支持的数据结构

• 对象：键值对的集合，又称为映射（mapping）、哈希（hashes）、字典（dictionary）
• 数组：一组按次序排列的值，又称为序列（sequence）、列表（list）
• 纯量：单个的，不可再分的值

对象类型：对象的一组键值对，使用冒号表示结构

name: czw
age: 18

yaml也允许另一种写法，将多有键值对协程一个行内对象

hash: { name: czw, age: 18}

数组类型：一组连词线开头的行，构成一个数组

animal
- Cat
- Dog

数组也可以才用行内表示法

animal: [Cat, Dog]

复合结构：对象和数组可以结合使用，形成符合结构

languages:
- Java
- Ruby
- Python
websites:
YAML: yaml.org
Ruby: ruby-lang.org

纯量：纯量是最基本的、不可再分的值。以下数据都属于纯量

字符串默认不使用引号

str: 这是一行字符串

如果字符串志忠包含空格或者特殊字符，需要放在引号之中，并且单引号和双引号都能用

str: '内容： 字符串'
str: "内容： 字符串"

单引号之中如果还有单引号，必须连续使用两个单引号转义

str: 'labor''s day'

字符串可以写成多行，从第二行开始，必须有一个但空格缩进，换行符会被转为空格

Str: 这个是一段
 多行
 字符串

多行字符串可以使用|保留换行符，也可以使用>折叠换行

this: |
  Foo
  Bar
that: >
Foo
Bar

+表示保留文字块末尾的换行(所以说+是默认存在的），-表示删除字符串末尾的换行

s1: |
  Foo
  
s2: |+
  Foo
  
s3: |-
  Foo

资源清单必须存在的属性

---

参数名	字段类型	说明
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[].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.restartPolicy	String	定义Pod的重启策略，可选值为Always、OnFailure，默认值为Always。1.Always: Pod—旦终止运行，则无论容器是如何终止的,kubelet服务都将重启它。2.OnFailure:只有Pod以非零退出码终止时，kubelet才会重启该容器。如果容器正常结束(退出码为0)，则kubelet将不会重启它。3.Never: Pod终止后，kubelet将退出码报告给Master，不会重启该Pod。
spec.nodeSelect	Object	定义Node的Label过滤标签，以key:value格式指定
spect.imagePullSecrets	Object	定义pull镜像时使用secret名称，以name:secretkey格式指定
spec.hostNetwork	Boolean	定义是否使用主机网络模式，默认值为false。设置true标识使用宿主机网络，不使用docker网桥，同事设置了true将无法在同一台宿主机上启动第二个副本

编写简单资源清单测试（pod模板）

pod.yaml
注意，kind值为Pod，不能小写

apiVersion: v1
kind: Pod
metadata: 
  name: myapp-pod
  namespace: default
  labels:
    app: myapp
spec:
  containers: 
  - name: app
    image: hub.atguigu.com/library/myapp:v1
  - name: test
    image: hub.atguigu.com/library/myapp:v1

生成资源

kubectl apply -f pod.yaml

查看状态，先进入Running状态，又进入Error状态

出现这个问题的原因也是很正常，咱们在yaml里面写了两个相同的pod所以端口肯定会冲突
查看日志（由于pod中有多个容器，所以添加参数-c），提示端口被占用

kubectl log myapp-pod -c test

删除镜像中重复的镜像，重新运行

kubectl delete pod myapp-pod
kubectl get pod
kubectl create -f pod.yaml
kubectl get pod

运行结果

访问

kubectl get pod -o wide
curl 10.244.2.13

容器生命周期

---

容器生命周期图

InitC （Init容器）

初始化容器，不会一直跟随pod的生命周期，数量在大于等于0。Pod 能够具有多个容器，应用运行在容器里面，但是它也可能有一个或多个先于应用容器启动的Init容器。如果Pod 的 Init容器失败，Kubernetes 会不断地重启该Pod，直到Init容器成功为止。然而，如果Pod 对应的restartPolicy为Never，它不会重新启动

Init容器与普通容器非常像，除了如下两点：

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

initC的作用

• 它们可以包含并运行实用工具，但是出于安全考虑，是不建议在应用程序容器镜像中包含这
  些实用工具的
• 它们可以包含使用工.具和定制化代码来安装，但是不能出现在应用程序镜像中。例如,
  镜像没必要FROM另一个镜像，只需要在安装过程中使用类似sed、awk、 python 或dig
  这样的工具。
• 应用程序镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像。Init容器使用Linux Namespace，所以相对应用程序容器来说具有不同的文件系统视图。因此，它们能够具有访问Secret的权限，而应用程序容器则不能。
• 它们必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以Init 容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法，直到满足了一组先决条件。例如在pod中发项目，里面包含MySQL与Apache整合PHP的项目，尽管他们有先后调用的顺序，但是MySQL可能启动缓慢，但php项目启动很快，导致服务对外访问的时候无法连接数据库，导致项目无限重启

InitC的应用

master、node1、node2执行指令，安装nslookup指令

yum -y install bind-utils

Init容器模板
init-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    # 运行一个myapp-container的pod，pod里面的组容器使用busybox的镜像，运行时输出语句“The app is running”，开始休眠6分钟
    command: ['sh', '-c', 'echo The app is running ! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox
    # dns会把metadata.name解析成IP，运行一个init-myservice的pod，检测解析是否成功，成功输出
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;' ]
  - name: init-mydb
    image: busybox
    # 检测mydb的svc是否启动成功，成功输出“waiting for mydb”，否则等待两秒后重复
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

删除所有deployment和所有的pod和svc

kubectl delete deployment --all
kubectl delete pod --all
kubectl get svc
kubectl delete svc nginx-deployment

myservice服务
myservice.yaml

apiVersion: v1
kind: Service
metadata: 
  name: myservice
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

mydb服务
mydb.yaml

kind: Service
apiVersion: v1
metadata:
  name: mydb
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9377

创建pod指令

kubectl create -f init-pod.yaml
kubectl create -f myservice.yaml
kubectl create -f mydb.yaml

等待一段时间后pod就可以被创建了

readiness

readinessProbe指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有Service的端点中删除该Pod 的IP地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为Success。就绪检测，pod在running状态但是pod中的服务还不能对外提供服务的状态

Liveness

livenessProbe指示容器是否正在运行。如果存活探测失败，则kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为Success。当pod中的nginx成为僵尸进程时，服务依旧在运行但是无法提供服务，此时需要销毁pod或者重启pod。

注意：readiness与Liveness没有与Main C左对齐是因为它们可以生命为在容器运行一定时间后进行检测

检测探针-就绪检测

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

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

自己定义资源清单生成容器测试探针，创建测试文件read.yaml。检测时会自动测试对应端口和测试网址所对应的网页，如果访问不了则kubectl get pod 的READY状态为0/1无法就绪

livenessProbe-httpget 方式就绪检测

apiVersion: v1
kind: Pod
metadata:
  name: readiness-httpget-pod
  namespace: default
spec:
  containers:
  - name: readiness-httpget-containers
    image: hub.atguigu.com/library/myapp:v1
    # 没有镜像就拉取
    imagePullPolicy: IfNotPresent
    readinessProbe:
      httpGet:
        # 测试端口
        port: 80
        # 就绪检测测试的网址
        path: /index1.html
      # 检测延时时长
      initialDelaySeconds: 1
      # 重试的检测时间
      periodSeconds: 3

创建pod容器

kubectl create -f read.yaml

查看容器状态

kubectl get pod

查看所有容器的内部详情，确实提示网页404

kubectl describe pod

以交互的方式进入pod中

kubectl exec readiness-httpget-pod -it -- /bin/sh

创建yaml文件中的检测文件index1.html

cd /usr/share/nginx/html
echo "hello readiness" >> index1.html

再次查看pod，状态正常

livenessProbe-exec脚本方式存活检测

liveness.yaml

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec-pod
  namespace: default
spec:
  containers:
  - name: liveness-exec-containers
    image: 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

执行结果如下图
分析：容器启动后创建/tmp/live文件夹，然后休眠60秒，存活检测参数initialDelaySeconds=1代表1一分钟之后进行检测，所以一分钟之前状态是正常的，检测方式就是检测/tmp/live目录是否存在，一分钟之后删除、tmp/live目录然后休眠6分钟，但是检测间隔是3秒一次，所以在一分钟之后存活检测由于/tmp/live不存在所以会干掉容器，容器的启动方式默认是always，所以容器会重启，启动次数会增加

livenessProbe-tcp 存活检测

livenessProbe-tcp

apiVersion: v1
kind: Pod
metadata:
  name: probe-tcp
spec:
  containers:
  - name: nginx
    image: hub.atguigu.com/library/myapp:v1
    livenessProbe:
      initialDelaySeconds: 5
      timeoutSeconds: 1
      tcpSocket:
        port: 8080
      periodSeconds: 3

由于检测的是8080端口，而myapp默认的是80端口，所以会一直重启

总结：就绪检测的作用是如果不就绪，那么容器状态不是READY，存活检测的作用是如果不存活容器就会被直接干掉

启动、退出动作

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: myapp:v1
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command:["/bin/sh", "-c", "echo Hello from the postStop handler > /usr/share/message"]

测试，退出无法测试

# 创建pod
kubectl create -f lifecycle-demo
# 进入pod
kubectl exec -it lifecycle-demo  -- /bin/sh
# 查看文件
cat /usr/share/message

Pod phase可能存在的值

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