本章内容：

1. Namespace
2. 镜像获取策略
3. 容器的重启策略
4. 健康检查      

LivenessProbe             生存探测

       ReadinessProbe    就绪探测

• Namespace：名称空间

1. k8s最核心的4个资源对象：

Namespace: 名称空间，一般用来隔离容器，提高控制性和安全性

Deployment:  最常见的无状态应用的控制器，支持应用的扩缩容、滚动更新等操作。

Servcie: 为弹性变动且存在生命周期的Pod对象提供了一个固定的访问接口，用于服务发现和服务访问。

Pod： 是运行容器以及调度的最小单位。

1. Namespace:名称空间

默认的名称空间： Default

1. 查看namespace

      [root@master01 ~]# kubectl get ns

     

      查看名称空间详细信息

      [root@master01 ~]# kubectl describe ns default

输出内容解释 ：

• Name：ns1 是该命名空间的名称。   
• Labels：kubernetes.io/metadata.name=ns1 是 Kubernetes 自动添加的标签，用于标识命名空间的名称。   
• Annotations：<none> 表示该命名空间没有自定义的注解（Annotations）。   
• Status：Active 表示该命名空间处于活跃状态。   
• No resource quota：表示该命名空间没有设置资源配额（Resource Quota）。资源配额用于限制命名空间中资源的使用，例如 CPU、内存、Pod 数量等。   
• No LimitRange resource：表示该命名空间没有设置 LimitRange 资源。LimitRange 用于限制命名空间中单个 Pod 或容器的资源使用，例如最小/最大 CPU 和内存限制。

1. 创建Namespace  ns1

      [root@master01 ~]#kubectl create ns ns1

      [root@master01 ~]# kubectl get ns

     

或用yaml清单文件配置：

[root@master01 ~]# mkdir yaml

[root@master01 ~]# cd yaml

[root@master01 yaml]# vim test-ns.yaml

apiVersion: v1

kind: Namespace

metadata:

  name: test

[root@master01 yaml]# kubectl apply -f test-ns.yaml

查看namespace

[root@master01 yaml]# kubectl get ns

注：namespace资源对象仅用于资源对象的隔离，并不能隔绝不同名称空间的Pod之间的通信，那是网络策略资源的功能。

查看指定名称空间的资源可以使用--namespace 或者-n 选项

1. 删除某个Namespace

[root@master01 yaml]# kubectl delete ns ns1

注：在执行删除某个名称空间的时候，千万注意，轻易不执行此操作，因为，如果执行之后，默认会将所有在此名称空间之下资源全部删除。

1. Namespace应用举例：

[root@master01 yaml]# vim ns1.yaml

---

apiVersion: v1

kind: Namespace

metadata:

  name: ns1

---

apiVersion: v1

kind: Pod

metadata:

  name: pod1

  namespace: ns1

spec:

  containers:

  - name: pod1

    image: httpd

[root@master01 yaml]# kubectl apply -f ns1.yaml

验证：

[root@master01 yaml]# kubectl get ns

[root@master01 yaml]# kubectl get pod -n ns1

补充：

1. 如果你希望限制该命名空间中资源的使用，可以创建一个 ResourceQuota 对象。例如：

限制的是ns1命名空间中的所占用的所有资源

[root@master01 yaml]# vim ns-quota.yml

apiVersion: v1

kind: ResourceQuota    #资源配额

metadata:

  name: ns1-quota

  namespace: ns1

spec:

  hard:   #硬限制

    requests.cpu: "2"           # 总 CPU 请求上限

    requests.memory: "4Gi"     # 总内存请求上限

    limits.cpu: "4"             # 总 CPU 限制上限

    limits.memory: "8Gi"       # 总内存限制上限

    pods: "10"                # 最大 Pod 数量

将资源配额应用到k8s集群中

[root@master01 yaml]# kubectl apply -f ns-quota.yml

查看命名空间ns1的详细信息

[root@master01 yaml]# kubectl describe ns ns1

1. 如果你希望限制单个 Pod 或容器的资源使用，可以创建一个 LimitRange 对象。例如：

[root@master01 yaml]#vim ns-limit.yml

apiVersion: v1

kind: LimitRange

metadata:

  name: ns1-limit-range

  namespace: ns1

spec:

  limits:

  - type: Container

    max:

      cpu: "500m"                 # 单个容器的最大 CPU 限制为 500m（0.5 核）

      memory: "1Gi"              # 单个容器的最大内存限制为 1GB

    min:

      cpu: "100m"                 # 单个容器的最小 CPU 请求为 100m（0.1 核）

      memory: "50Mi"           # 单个容器的最小内存请求为 50MB

[root@master01 yaml]# kubectl apply -f ns-limit.yml

[root@master01 yaml]# kubectl describe ns ns1

• Pod中镜像获取策略：

1. k8s默认根据镜像的TAG不同，有3中获取策略。

1. Always： 镜像标签为"latest"或镜像标签不存在时，总是从指定的仓库（默认的官方仓库、或者私有仓库）中获取最新镜像。

1. IfNotPresent：仅当本地镜像不存在时才从目标仓库中下载。也就意味着，如果本地存在，直接使用本地镜像，无需再联网下载。

1. Never: 禁止从仓库中下载镜像，即只使用本地镜像。

注：对于标签为“latest”或者标签不存在的镜像，其镜像默认下载策略为“Always”，

而对于其他标签的镜像，默认则使用了“IfNotPresent”.

1. Pod默认镜像获取策略：

在worker01和worker02节点上提前下载httpd镜像，用于验证下载策略  

执行命令：docker pull httpd

自主式的pod 不支持副本和template

[root@master01 yaml]#   vim pod1.yaml

---

apiVersion: v1

kind: Namespace

metadata:

  name: ns1

---

apiVersion: v1

kind: Pod

metadata:

  name: test-pod

  namespace: ns1

spec:

  containers:

  - name: test-web

    image: httpd

对于标签为“latest”或者标签不存在，其默认镜像下载策略为“Always”

验证：

[root@master01 yaml]# kubectl apply -f pod1.yaml

[root@master01 yaml]# kubectl -n ns1 describe pod test-pod            #名称在前，tab方便

 等同于

[root@master01 yaml]# kubectl describe pod test-pod -n ns1

1. 将上述Pod资源的镜像下载策略改为IfNotPresent.

[root@master01 yaml]#  vim pod2.yaml

apiVersion: v1

kind: Pod

metadata:

  name: pod1

spec:

  containers:

  - name: pod1

    image: httpd

    imagePullPolicy: IfNotPresent

验证：

[root@master01 yaml]#  kubectl apply -f pod2.yaml

[root@master01 yaml]#  kubectl describe pod pod1

• 容器的重启策略

1. 容器终止时的处理策略（不是删除，如果有副本控制器的话，删除会重建）：

1. Always：  但凡Pod对象终止就将其重启，即使正常终止也重启，此为默认设定。

1. OnFailure:  仅在Pod对象出现错误时才将其重启。

1. Never:  从不重启。

[root@master01 yaml]#  vim always.yaml

apiVersion: v1

kind: Pod

metadata:

  name: pod2

spec:

  containers:

  - name: pod2

    image: httpd

    imagePullPolicy: IfNotPresent

验证：

[root@master01 yaml]#  kubectl apply -f always.yaml

[root@master01 yaml]#  kubectl get pod -o wide

[root@worker02 ~]# docker ps -a | grep pod2

[root@worker02 ~]# docker stop 4ae585fa0497

[root@worker02 ~]# docker ps -a | grep pod2

发现：原来的容器被停止之后会重新启动一个新容器

1. 重启策略为OnFailure示例：

不用做

[root@worker02 ~]# vim onfailure1.yaml（生产配置如下，演示效果看下一个示例）

apiVersion: v1

kind: Pod

metadata:

  name: pod2

  namespace: ns1

spec:

  containers:

  - name: pod2

    image: httpd

    imagePullPolicy: IfNotPresent

  restartPolicy: OnFailure

  terminationGracePeriodSeconds: 30

# 注：

在 Kubernetes 的 Pod 配置中，terminationGracePeriodSeconds 是一个重要的字段，用于指定在删除 Pod 时，Kubernetes 会给 Pod 多长时间来优雅地终止其进程。这个字段的值是一个整数，表示秒数。

1. pod重启策略OnFailure（演示效果如下）

容器终止返回值为1，重启容器

容器终止返回值为0，不重启容器

[root@master01 yaml]#  vim  onfailure2.yaml

apiVersion: v1

kind: Pod

metadata:

  name: pod3

spec:

  restartPolicy: OnFailure

  containers:

  - name: pod3

    image: busybox

    imagePullPolicy: IfNotPresent

    args:

    - /bin/sh

    - -c

    - sleep 10; exit 1

#模拟pod异常退出了。给了一个退出状态码，值为1 结合pod重启策略验证

[root@master01 yaml]# kubectl apply -f onfailure2.yaml

[root@master01 yaml]# kubectl get pod -w 

#执行查看完整状态过程和重启次数，-w选项持续监控

CrashLoopBackOff崩溃循环后退

是一种在Kubernetes中常见的状态，它表示Pod中的容器在启动后不断崩溃并重新启动，形成一个循环。Kubernetes会在每次重新启动之间等待一个越来越长的Backoff时间，以便有足够的时间来修复错误。

如果此时，我们将退出状态码改为0，也就是正常退出，仍使用OnFailure策略，但它就不会重启Pod了

[root@master01 yaml]# kubectl delete pod pod3

[root@master01 yaml]# vim onfailure3.yaml

kind: Pod

apiVersion: v1

metadata:

  name: pod3

spec:

  restartPolicy: OnFailure

  containers:

  - name: pod3

    image: busybox

    imagePullPolicy: IfNotPresent

    args:

    - /bin/sh

    - -c

    - sleep 10; exit 0

 

[root@master01 yaml]# kubectl apply -f onfailure3.yaml

[root@master01 yaml]# kubectl get pod -w 

#执行查看完整状态过程和重启次数，-w选项持续监控

• Pod健康检查：探针检查

1. 1. Pod健康检查类型

      LivenessProbe        生存探测

      ReadinessProbe     就绪探测

1. 1. 1. LivenessProbe(活跃度、存活性)

[root@master01 ~]# vim  liveness.yaml

apiVersion: v1

kind: Pod

metadata:

  name: liveness

  labels:

    test: liveness          #通过标签选择器和svc资源关联

spec:

  restartPolicy: OnFailure  #配置pod的重启策略

  containers:

  - name: liveness

    image: busybox

    imagePullPolicy: IfNotPresent

    args:

    - /bin/sh

    - -c

    - touch /tmp/test; sleep 30; rm -rf /tmp/test; sleep 300

    livenessProbe:

      exec:

        command:

        - cat

        - /tmp/test

      initialDelaySeconds: 10     #Pod运行10秒后开始探测

      periodSeconds: 5                #每5秒探测一次

#命令sleep 30; rm -rf /tmp/test; sleep 300  仅为模拟故障现象

#在容器里面创建一个文件，在存活性字段中执行动作判断这个文件存在与否，根据返回值来和重启策略联动。先休眠30秒，这期间文件肯定存在，之后往下按照存活检测规则判断并得到返回值。

Liveness活跃度探测，根据探测某个文件是否存在，来确认某个服务是否正常运行，如果存在则正常，否则它会根据你设置的Pod的重启策略操作Pod。

[root@master01 ~]# kubectl apply -f liveness.yaml

[root@master01 ~]# kubectl get pods

[root@master01 ~]# kubectl get pod liveness -w

可以看到重启策略生效了

CrashLoopBackOff崩溃循环后退

是一种在Kubernetes中常见的状态，它表示Pod中的容器在启动后不断崩溃并重新启动，形成一个循环。Kubernetes会在每次重新启动之间等待一个越来越长的Backoff时间，以便有足够的时间来修复错误。

1. 1. 1. Readiness（敏捷探测、就绪性探测）

[root@master01 yaml]# vim readiness.yaml

apiVersion: v1

kind: Pod

metadata:

  name: readiness

  labels:

    test: readiness         #通过标签选择器和svc资源关联

spec:

  restartPolicy: OnFailure       #此处重启策略不会被触发，此次标识无意义

  containers:

  - name: readiness

    image: busybox

    imagePullPolicy: IfNotPresent

    args:

    - /bin/sh

    - -c

    - touch /tmp/test; sleep 30; rm -rf /tmp/test; sleep 300

    readinessProbe:

      exec:

        command:

        - cat

        - /tmp/test

      initialDelaySeconds: 10

      periodSeconds: 5

#readiness判断关键文件是否存在后，而决定pod的状态，这点和liveiness一样，

不同点在于他并不会触发对pod操作和重启策略，而是会将pod设置为不可用状态

readinessProbe: 定义了一个就绪探针，用于检查容器是否准备好提供服务。

exec: 执行一个命令来检查容器的就绪状态。

command: 执行 cat /tmp/test 命令，检查文件 /tmp/test 是否存在。

initialDelaySeconds: 在容器启动后等待 10 秒才开始执行就绪探针。

periodSeconds: 每 5 秒执行一次就绪探针。

[root@master01 yaml]# kubectl apply -f readiness.yaml

[root@master01 ~]# kubectl get pod readiness -w

--------------------------------------------------------------------------------------------------------

1. 1. 应用示例：结合一个service资源在pod扩容中应用

[root@master01 ~]# vim myweb2.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: myweb2

spec:

  selector:

    matchLabels:  

      run: web2

  replicas: 3

  template:

    metadata:

      labels:

        run: web2

    spec:

      containers:

      - name: web2

        image: httpd:latest

        imagePullPolicy: IfNotPresent

        ports:

        - containerPort: 80

        readinessProbe:

          httpGet:

            scheme: HTTP

            path: /healthy                

            port: 80

          initialDelaySeconds: 10

          periodSeconds: 5

---

apiVersion: v1

kind: Service

metadata:

  name: web-svc

spec:

  type: NodePort

  selector:

    run: web2

  ports:

  - port: 90

    targetPort: 80

    nodePort: 30111

注释：上面配置的作用是

          httpGet:                           

            scheme: HTTP

            path: /healthy                

            port: 80

          initialDelaySeconds: 10

          periodSeconds: 5

#返回的是访问80端口后的健康码 200-400之间为正常，针对的是pod中的服务是否正常启动

#指的是httpd镜像网站根目录下的healthy文件，生产环境可以指定主页文件，如index.html

此镜像启动后默认有index.html，为测试效果而随意创建了一个文件healthy

容器启动 10 秒之后开始探测。

如果 http://[container_ip]:8080/healthy 返回代码不是 200-400，表示容器没有就绪，不接收 Service web-svc 的请求。

每隔 5 秒再探测一次。

直到返回代码为 200-400，表明容器已经就绪，然后将其加入到 web-svc 的负载均衡中，开始处理客户请求。

探测会继续以 5 秒的间隔执行，如果连续发生 3 次失败，容器又会从负载均衡中移除，直到下次探测成功重新加入。

[root@master01 yaml]# kubectl apply -f myweb2.yaml   

[root@master01 yaml]# kubectl get pod

如果没有health网页的话表示pod没有就绪（虽然显示running但是并没有运行）

#进入其中一个容器根目录，创建healthy文件

[root@master01 ~]# kubectl exec -it myweb2-549b4ff75c-jbpx5 -- /bin/bash

root@myweb2-549b4ff75c-jbpx5:/usr/local/apache2# ls

bin  build  cgi-bin  conf  error  htdocs  icons  include  logs  modules

root@myweb2-549b4ff75c-jbpx5:/usr/local/apache2# cd htdocs/

root@myweb2-549b4ff75c-jbpx5:/usr/local/apache2/htdocs# touch healthy

root@myweb2-549b4ff75c-jbpx5:/usr/local/apache2/htdocs# ls

healthy  index.html

如果没有上传网页的话，pod不会就绪，只有上传了网页才会真正运行

[root@master01 yaml]# kubectl get svc,pod

只有一个容器上传了网页，上传了网页的容器才会真正运行

[root@master01 yaml]# kubectl describe svc web-svc

三个容器都上传网页后都就绪的话就会显示三个IP

总结liveness和 readiness探测

1）liveness和readiness是两种健康检查机制，如果不特意配置，k8s将两种探测采取相同的默认行为，即通过判断容器启动进程的返回值是否为零，来判断探测是否成功。

2）两种探测配置方法完全一样，不同之处在于探测失败后的行为：

      liveness探测是根据Pod重启策略操作容器，大多数是重启容器。

     readiness则是将容器设置为不可用，不接收Service转发的请求，不执行容器重启策略。

1. 两种探测方法可以独立存在，也可以同时使用。用liveness判断容器是否需要重启实现自愈；用readiness判断容器是否已经准备好对外提供服务。

实验要求：

1. 完成namespace创建、查看过程
2. 完成镜像获取策略的验证过程
3. 完成容器重启策略的验证过程
4. 完成容器健康检查   验证过程

LivenessProbe        生存探测

      ReadinessProbe     就绪探测