Kubernetes--深入理解Pod资源管理

已于 2025-06-13 16:35:46 修改
阅读量1.2k 收藏 19
点赞数 28
CC 4.0 BY-SA版权
分类专栏： K8s+docker 文章标签： kubernetes 容器 云原生
于 2024-10-08 11:00:59 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/flytalei/article/details/142735135

文章目录

kubectl --help

kubectl 是 Kubernetes 命令行工具，允许用户与 Kubernetes 集群进行交互。通过 kubectl，用户可以创建、查看、更新、删除集群中的各种资源（如 Pod、Service、Deployment 等），并且可以调试和管理 Kubernetes 集群。

root@k8s-master01:~# kubectl --help
kubectl controls the Kubernetes cluster manager.

 Find more information at: https://kubernetes.io/docs/reference/kubectl/

Basic Commands (Beginner):
  create          Create a resource from a file or from stdin
  expose          Take a replication controller, service, deployment or pod and expose it as a new Kubernetes service
  run             Run a particular image on the cluster
  set             Set specific features on objects

Basic Commands (Intermediate):
  explain         Get documentation for a resource
  get             Display one or many resources
  edit            Edit a resource on the server
  delete          Delete resources by file names, stdin, resources and names, or by resources and label selector

Deploy Commands:
  rollout         Manage the rollout of a resource
  scale           Set a new size for a deployment, replica set, or replication controller
  autoscale       Auto-scale a deployment, replica set, stateful set, or replication controller

Cluster Management Commands:
  certificate     Modify certificate resources.
  cluster-info    Display cluster information
  top             Display resource (CPU/memory) usage
  cordon          Mark node as unschedulable
  uncordon        Mark node as schedulable
  drain           Drain node in preparation for maintenance
  taint           Update the taints on one or more nodes

Troubleshooting and Debugging Commands:
  describe        Show details of a specific resource or group of resources
  logs            Print the logs for a container in a pod
  attach          Attach to a running container
  exec            Execute a command in a container
  port-forward    Forward one or more local ports to a pod
  proxy           Run a proxy to the Kubernetes API server
  cp              Copy files and directories to and from containers
  auth            Inspect authorization
  debug           Create debugging sessions for troubleshooting workloads and nodes
  events          List events

Advanced Commands:
  diff            Diff the live version against a would-be applied version
  apply           Apply a configuration to a resource by file name or stdin
  patch           Update fields of a resource
  replace         Replace a resource by file name or stdin
  wait            Experimental: Wait for a specific condition on one or many resources
  kustomize       Build a kustomization target from a directory or URL

Settings Commands:
  label           Update the labels on a resource
  annotate        Update the annotations on a resource
  completion      Output shell completion code for the specified shell (bash, zsh, fish, or powershell)

Other Commands:
  api-resources   Print the supported API resources on the server
  api-versions    Print the supported API versions on the server, in the form of "group/version"
  config          Modify kubeconfig files
  plugin          Provides utilities for interacting with plugins
  version         Print the client and server version information

Usage:
  kubectl [flags] [options]

Use "kubectl <command> --help" for more information about a given command.
Use "kubectl options" for a list of global command-line options (applies to all commands).

api-resources

kubectl api-resources 命令用于列出 Kubernetes API 中的所有资源及其对应的组、版本、类别等详细信息。在 Kubernetes中，资源是指各种对象类型，例如Pods、Services、Deployments 等，API是这些资源的入口点。通过 kubectl api-resources，你可以查看集群中支持的所有资源，并了解如何使用它们。

kubectl api-resources

以下是kubectl api-resources的部分截图
在这里插入图片描述
api-resources常见列项解释：

常见列项解释：
  1.NAME：列出了资源的名称。例如 pods 表示 Pod 资源。
  
  2.SHORTNAMES：资源名称的简写形式。例如 po是pods的简写，svc是services的简写。
  
  3.APIGROUP：资源的API组，Kubernetes 将API资源按组分类。核心资源（如 pods 和 services）没有API组，因此该列为空。
      3.1.核心API组的资源不需要在使用时指定API组。例如，kubectl get pods可以直接访问Pod资源。
      3.2.其他API组的资源需要通过 kubectl 指定 API 组，例如 kubectl get deployments.apps。
      
  4.NAMESPACED：如果为true，表示该资源是基于命名空间的，资源只能在特定命名空间内创建和管理。如果为 false，表示该资源在集群范围内全局可用。
  
  5.KIND：资源的类型或类。例如 Pod、Deployment、Services等。

api-versions

kubectl api-versions 是一个 Kubernetes 命令，用于列出集群当前支持的所有 API 版本。在 Kubernetes 中，API 是与集群交互的核心，API 版本管理允许 Kubernetes 保持向后兼容性，并引入新功能而不破坏现有的功能。

kubectl api-versions

常见的API版本包括：
  1. v1：核心API组中常见的版本，是最稳定的。
  2. apps/v1、batch/v1等：这些是非核心API组，包含不同功能模块的API版本。
  3. Alpha、Beta和Stable阶段的API版本，表示功能的成熟度。

在这里插入图片描述

输出的解释
  1.apps/v1：表示apps API组中的版本v1，用于管理应用相关资源（如 Deployment、StatefulSet 等）。
  2.batch/v1：表示batch API组中的版本v1，用于管理批处理作业（如 Job 和 CronJob）。
  3.autoscaling/v1：表示autoscaling API组中的版本v1，用于管理自动扩缩容功能（如   HorizontalPodAutoscaler）。
  4.v1：表示核心API组中的版本 v1，用于管理核心资源（如 Pod、Service、Node、Namespace 等）。

API 版本的阶段

Kubernetes中的API版本分为以下几个阶段：
  1.Alpha：
    可能有重大变更，不建议在生产环境中使用。
    默认情况下不启用，通常需要使用特定的配置来启用。
    例如：batch/v2alpha1

  2.Beta：
    较为稳定，且默认启用。
    可能仍然会有变更，但使用在生产环境中是可接受的。
    例如：apps/v1beta1。
  
  3.Stable：
    已经经过长期测试，并被认为是安全且稳定的。
    推荐在生产环境中使用。
    例如：apps/v1。

kubectl explain …

kubectl explain 是 Kubernetes 中用于查看资源的详细信息及其字段解释的命令。它帮助用户了解 Kubernetes 资源的结构和字段意义，特别是当你编写 YAML 文件或者需要修改资源时，kubectl explain 是一个非常有用的工具。

kubectl explain Deployment

打印Deployment的说明文档
在这里插入图片描述

kubectl explain Deployment.spec

root@k8s-master01:~# kubectl explain Deployment.spec
GROUP:      apps
KIND:       Deployment
VERSION:    v1

FIELD: spec <DeploymentSpec>

DESCRIPTION:
    Specification of the desired behavior of the Deployment.
    DeploymentSpec is the specification of the desired behavior of the
    Deployment.
    
FIELDS:
  minReadySeconds	<integer>
    Minimum number of seconds for which a newly created pod should be ready
    without any of its container crashing, for it to be considered available.
    Defaults to 0 (pod will be considered available as soon as it is ready)

  paused	<boolean>
    Indicates that the deployment is paused.

  progressDeadlineSeconds	<integer>
    The maximum time in seconds for a deployment to make progress before it is
    considered to be failed. The deployment controller will continue to process
    failed deployments and a condition with a ProgressDeadlineExceeded reason
    will be surfaced in the deployment status. Note that progress will not be
    estimated during the time a deployment is paused. Defaults to 600s.

  replicas	<integer>
    Number of desired pods. This is a pointer to distinguish between explicit
    zero and not specified. Defaults to 1.

  revisionHistoryLimit	<integer>
    The number of old ReplicaSets to retain to allow rollback. This is a pointer
    to distinguish between explicit zero and not specified. Defaults to 10.

  selector	<LabelSelector> -required-
    Label selector for pods. Existing ReplicaSets whose pods are selected by
    this will be the ones affected by this deployment. It must match the pod
    template's labels.

  strategy	<DeploymentStrategy>
    The deployment strategy to use to replace existing pods with new ones.

  template	<PodTemplateSpec> -required-
    Template describes the pods that will be created. The only allowed
    template.spec.restartPolicy value is "Always".

在这里插入图片描述

API资源

Kubernetes API 中的资源包括不同的对象类型，如 Pod、Service、Deployment 等。每个资源都可以使用 YAML 或 JSON 格式来定义，并通过 API server 进行管理。不同资源代表 Kubernetes 中不同的组件和配置。

Kubernetes 中的 API 资源是与 Kubernetes 对象和操作交互的核心。Kubernetes 的 API 提供了访问集群中所有资源的途径，无论是用 kubectl 命令行工具，还是通过编程接口进行操作。

API: RESTful API
  Resource
    Deployment --> demoapp --> Controller执行
    Service

    资源类型 --> 对象 --> 实体
       对象：用户期望的状态 
       实体：实际状态 

   小汽车：资源类型
     发动机：
     变速箱

资源规范

Pod

Pod：最基本的计算单元，容纳一个或多个容器，具有共享的网络和存储。

 Pod：
   资源规范：
     apiVersion: GROUP/VERSION
       ~# kubectl api-versions
     kind：KIND
       ~# kubectl api-resources
     metadata:
       name: <NAME>
         名称空间级别的资源：同一名称空间下，同一类型中，必须惟一；
       namespace: <NAMESPACE>
       labels: 
         key1: val1
         key2: val2
       annotations:
         key1: val1
         ...
       spec: 
         ~# kubectl explain KIND.spec

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: nginx

Service

Service：定义一组 Pod 的访问方式，通过固定 IP 或 DNS 名称对外暴露服务。

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

ConfigMap

ConfigMap：用于存储配置信息的键值对。

apiVersion: v1
kind: ConfigMap
metadata:
  name: myconfigmap
data:
  key: value

Secret

Secret：用于存储敏感数据（如密码、token）。

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  password: cGFzc3dvcmQ=

Namespace

Namespace名称空间是Kubernetes集群提供对内部资源进行“软隔离”的机制，以方便用户管理和组织集群资源。可以将其想像成虚拟的“子集群”

Kubernetes 中的 Namespace 是一种用于在同一个集群中划分多个虚拟集群的机制。通过使用命名空间，Kubernetes 可以将资源隔离开来，使多个团队或应用能够在同一个物理集群上安全、独立地工作。它主要用于资源的组织、权限的隔离以及对不同用户或应用组的资源配额管理。

Namespace 的作用

Namespace 的作用
  1.资源隔离：
      不同命名空间下的资源（如 Pods、Services、ConfigMaps 等）是相互隔离的。
      同名的资源可以存在于不同的命名空间中，不会产生冲突。
  
  2.权限管理：
      结合 Kubernetes 的 RBAC（基于角色的访问控制），可以在命名空间的级别上限制用户的权限。
      例如，一个用户只可以管理特定命名空间中的资源。
  
  3.资源配额：
      通过配置资源配额（Resource Quotas），
      可以限制某个命名空间可以使用的 CPU、内存等资源，防止一个团队或应用过度占用集群资源。
  
  4.简化多租户管理：
      对于有多个团队或项目共用同一个 Kubernetes 集群的情况，可以通过 Namespace 实现资源隔离，
      保证每个团队或项目有独立的工作空间。

Namespace 的使用场景

Namespace 的使用场景
  1.'开发、测试和生产环境的隔离'：
      在实际工作中，可以为开发、测试和生产环境创建不同的命名空间，
      例如 dev、test 和 prod。
      这样即便是在同一个物理集群上，也可以确保不同环境中的应用相互独立，避免开发和测试中的错误影响到生产环境。

  2.'多租户系统'：
      当多个团队或项目共享同一个 Kubernetes 集群时，可以为每个团队或项目分配独立的命名空间。
      每个团队只需要管理自己的命名空间，集群管理员可以通过资源配额和 RBAC 实现对资源使用的管理和限制。

  3.'微服务架构中的应用隔离'：
       在微服务架构中，不同的服务可以部署在不同的命名空间中。
       例如，一个命名空间可以专门用于业务服务，另一个命名空间可以用于基础设施服务，如数据库、消息队列等。

常用的 Namespace 命令

kubectl get namespaces                     列出所有命名空间

kubectl create namespace <namespace-name>  创建命名空间

kubectl delete namespace <namespace-name>  删除命名空间

kubectl get pods -n <namespace-name>       查看某个命名空间中的资源

kubectl config set-context --current --namespace=<namespace-name>   切换命名空间的上下文

实际应用举例

示例 1：隔离开发、测试和生产环境

假设一个公司正在使用 Kubernetes 进行微服务部署，应用的生命周期分为开发（dev）、测试（test）和生产（prod）三个阶段。可以为每个阶段创建单独的命名空间：

kubectl create namespace dev
kubectl create namespace test
kubectl create namespace prod

每个阶段的应用、配置文件、Secrets 等都部署在相应的命名空间中。这样做可以保证开发人员不会意外修改生产环境中的资源。

示例 2：多团队协作

假设一个公司有两个团队 TeamA 和 TeamB，他们共享同一个 Kubernetes 集群。为了避免资源冲突和权限问题，管理员可以为每个团队创建独立的命名空间：

kubectl create namespace team-a
kubectl create namespace team-b

管理员通过 RBAC 限制每个团队只能管理自己的命名空间，确保资源隔离。每个团队都可以创建相同名称的服务、Pod 或其他资源，而不会互相干扰。

示例 3：资源配额管理

为了防止某个团队使用过多的集群资源，可以为每个命名空间设置资源配额。例如，限制 team-a 命名空间最多可以使用 4 个 CPU 和 8GB 内存：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"

通过这种方式，团队可以合理分配资源，防止资源耗尽影响到整个集群的性能。

Kubernetes 的 Namespace 是一种重要的资源管理和隔离手段，特别适用于多租户、多团队合作以及开发、测试、生产环境的隔离。在实际工作中，命名空间可以通过权限控制和资源配额管理等手段，确保 Kubernetes 集群中的资源高效、安全地被使用。

资源操作

资源清单YML

先写资源清单时，如果不清楚具体的配置怎么写，可以参考k8s系统中现有的资源清单。
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

yaml参数说明

apiVersion: v1   # api文档版本
kind: Pod        # 资源对象类型，也可以配置为像Deployment、StatefulSet这一类的对象
metadata:        # Pod相关的元数据，用于描述Pod的数据
  name: nginx-demo   # Pod 的名称
  labels:            # 定义 Pod 的标签
    type: app        # 自定义 label标签，名字为type，值为app
    test: 1.0.0      # 自定义label标签，描述Pod版本号
  namespace: 'default'    # 命名空间的配置
spec:                     # 期望Pod按照这里面的描述进行创建  #就是specification
  containers:             # 对于Pod中的容器描述
  - name: nginx           # 容器的名称
    image: nginx:1.7.9    # 指定容器的镜像
    imagePullPolicy: IfNotPresent   #镜像拉取策略，指定如果本地有就用本地的，如果没有就拉取远程的
    command:          # 指定容器启动时执行的命令 
    - nginx
    - -g
    - 'daemon off'   # nginx -g 'daemon off;'
    workingDir: /usr/share/nginx/html    # 定义容器启动后的工作目录
    ports:
    - name: http            # 端口名称
      containerPort: 80     # 描述容器内要暴露什么端口
      protocol: TCP         # 描述该端口是基于哪种协议通信的
    env:                 #  环境变量
    - name: JVM_OPTS     #  环境变量名称
      value: '-Xms128m -Xmx128m'  # 环境变量的值
    resources:
      requests:          # 最少需要多少资源
        cpu: 100m        # 限制cpu最少使用 0.1个核心
        memory: 128Mi    # 限制内存最少使用128M
      limits:            # 最多可以用多少资源
        cpu: 200m        # 限制cpu最多使用0.2个核心
        memory: 256Mi    # 限制最多使用256M
   restartPolicy: OnFailure   # 重启策略，只有在失败的情况下才重启

spec 是 specification（规范、规格说明）的缩写。
在 Kubernetes YAML 文件中，spec 表示对某个资源的期望状态的详细说明，即你希望这个资源“应该怎么运行、应该是什么样子”。

创建资源

创建资源
  kubectl create -f <resource.yaml>
  kubectl apply -f <resource.yaml>

kubectl apply 和 kubectl create 是 Kubernetes 中用于管理资源的两种主要命令，尽管它们都用于创建资源，但它们在行为和使用场景上有明显的区别。
在这里插入图片描述

kubectl create

kubectl create用于在集群中创建新的资源。该命令通常用于一次性创建一个资源，不能用于更新现有资源。如果资源已经存在，kubectl create 将会返回错误，提示资源已存在。

kubectl apply

kubectl apply 用于创建和更新资源。它基于声明式管理方式，允许你定义资源的所需状态，并持续对其进行更新。kubectl apply 会比较资源的当前状态和配置文件中的声明状态，如果有差异，它会更新资源以匹配配置文件。

如果原来副本数为3，后来修改为5执行 kubectl apply 后，Deployment 的副本数会从 3 更新为 5。

显示资源

显示资源：
  kubectl get TYPE [NAME ...] -o {wide|yaml|json}

  kubectl get TYPE/NAME ... -o {wide|yaml|json}

删除资源

删除资源：
  kubectl delete TYPE [NAME ...]

  kubectl delete TYPE/NAME ...

详细描述

详细的状态描述：
  kubectl describe TYPE [NAME ...]

  kubectl describe TYPE/NAME ...

RESTful API

RESTful API 是一种基于 REST（Representational State Transfer）架构风格的网络服务设计方法。它通过标准的 HTTP 协议来操作和访问服务器上的资源（数据），常用于开发面向 Web 的应用程序。

RESTful API 设计遵循一些关键原则和约定，它们使得 API 更加简单、统一、可扩展。

RESTful API 的核心概念：
  1.资源（Resource）：
     在REST中，服务器上的每个对象或数据都被视为资源，
     通常以 URI（Uniform Resource Identifier，统一资源标识符）来表示。例如，资源可以是用户、商品、订单等数据。
     例如：/users 代表所有用户，/users/1 代表 ID 为 1 的用户。
     
  2.HTTP方法（HTTP Methods）：
     RESTful API 使用 HTTP 协议的不同方法来执行操作，这些操作与数据库的增删改查（CRUD）操作非常相似。
       GET：获取资源，类似于数据库查询（Read）。
       POST：创建新资源，类似于数据库插入（Create）。
       PUT：更新资源，类似于数据库更新（Update）。
       DELETE：删除资源，类似于数据库删除（Delete）。
  
  3.状态无关（Stateless）：
     RESTful API是无状态的，这意味着每个请求都应该包含所有必要的信息，服务器不会保存客户端的状态。
     每个请求是独立的。
  
  4.表述（Representation）：
     资源在服务器端以不同的形式存在，客户端通过请求可以获取资源的表述（如 JSON、XML），常用的表示格式是 JSON。
  
  5.统一接口（Uniform Interface）：
     API应该提供一致的接口设计，遵循通用的资源表示和操作方式，使得API易于使用和理解。

RESTful API：   
  资源对象管理的基本操作：CRUD
    Create
    Read
    Update
    Delete

    Create:
      kubectl create
    Read:
      kubectl get/describe
    Update: 
      kubectl edit/patch/replace/set
    Delete:
      kubectl delete

  HTTP协议
    method：
      GET
      POST
      PUT
      DELETE
      OPTIONS
      ...

Pod资源管理

Pod是Kubernetes可调度、部署和运用的最小原子单元。Pod是一个或多个容器的集合，因而也可称之为容器集。

Pod的核心概念

Pod的核心概念
  1.Pod是Kubernetes中最小的可部署单元
    在Kubernetes中，Pod是容器的抽象，而不是直接管理容器。
    一个Pod运行一个或多个应用容器，多个容器共享同一网络命名空间、存储卷，并且它们的生命周期也完全一致。

  2.Pod内的多容器
    Pod支持多个容器共同运行，称为sidecar模式，所有容器共享同一个网络和存储。
    例如，一个容器负责处理应用的主逻辑，而另一个容器可以作为日志聚合器或监控代理。

  3.共享网络和存储
    Pod中的所有容器共享相同的IP地址和网络端口范围，
    这意味着同一个Pod内的容器可以通过localhost直接通信，而不需要通过网络寻址。
    同样，Pod中的容器也可以共享存储卷，方便多个容器访问相同的数据。

  4.Pod的生命周期
    Pod的生命周期是短暂的、不可持久的，Pod可能会因为各种原因被重新调度或重新创建。
    Kubernetes 不会重新启动已死的 Pod，而是会创建一个新的Pod来替代。
    为了管理Pod的生命周期，通常会通过控制器（如 Deployment、DaemonSet等）来确保Pod的可用性。

Pause容器

在Kubernetes中，Pause 容器是一个轻量级容器，主要用于为Pod中的其他容器提供网络和共享的命名空间，如网络、进程、文件系统等。它本身没有实际的应用逻辑，只是在后台运行以维持这些命名空间，确保Pod内的多个容器能够相互通信、共享资源。

Pause 容器的作用

Pause 容器的作用

  1.管理命名空间：
      Kubernetes中的Pod是由多个容器组成的最小部署单元，而这些容器共享同一个网络命名空间、进程命名空间等。
      Pause 容器的作用就是为这些命名空间的共享提供基础。
      
  2.保持生命周期管理：
      Pause 容器是Pod中第一个启动的容器，并且在整个Pod生命周期中持续运行。
      如果它停止运行，整个Pod就会认为已崩溃，导致其他容器也会被销毁。
      
  3.网络管理：
      在Kubernetes中，每个Pod都有一个独立的IP地址，所有容器共享这个IP地址和网络栈。
      Pause 容器会创建并持有该网络栈，以便其他容器能够使用相同的网络环境。
      
  4.隔离资源：
      除了网络命名空间，Pause 容器还可以帮助多个容器共享或隔离其他资源，比如文件系统挂载点、进程ID命名空间等。

工作原理

当Kubernetes创建一个Pod时，Pause 容器首先启动，并负责建立和保持整个Pod的基础命名空间。之后，其他应用容器会在这个命名空间中启动，并与Pause容器共享这些资源。

例如，假设有一个Pod包含两个容器：nginx 和 sidecar。当Pod启动时，首先启动Pause 容器，创建网络命名空间和其他共享资源，然后 nginx 和 sidecar 容器在同一个命名空间中启动。这样，nginx 和 sidecar 容器可以通过localhost相互通信，因为它们共享相同的网络栈。

举例说明
假设我们有一个Pod的YAML文件如下：

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: nginx
    image: nginx
  - name: sidecar
    image: busybox
    command: ["sh", "-c", "while true; do echo hello; sleep 10;done"]

在这个Pod中，有两个容器：nginx和sidecar。在实际运行时，Kubernetes会自动启动一个Pause 容器，它先负责创建Pod的网络命名空间，确保两个容器能够共享相同的网络环境。然后 nginx 和 sidecar 容器在这个命名空间中启动。

具体步骤：
  1.Kubernetes首先启动Pause容器，该容器会初始化Pod的网络和其他命名空间。
  2.nginx 和 sidecar 容器随后启动，它们共享同一个网络栈，这意味着nginx可以通过localhost访问sidecar，反之亦然。

实际生产场景中的使用

在生产环境中，Pause 容器是Kubernetes调度Pod的一个重要机制，虽然我们在定义Pod时不会显式地指定它，但它在幕后发挥着重要作用。

Pause容器它确保了：
  1.Pod内多个容器之间的网络通信可以顺利进行。
  2.资源的隔离和共享。
  3.在Pod的整个生命周期中维持命名空间的一致性。

对于调试网络问题或分析容器运行环境，理解Pause 容器的工作原理是非常关键的。例如，当我们检查Pod的网络命名空间时，实际的网络配置是由Pause 容器提供的。

Pause 容器作为Kubernetes中的幕后角色，确保Pod内部多个容器能够共享命名空间和资源，同时管理它们的生命周期。它是Pod正常工作的重要基础，尤其在处理网络、进程等共享资源时，起到了至关重要的作用。

Pod资源配置

以下是一个指定了Nginx版本的 Kubernetes Pod资源配置示例，在该 Pod 中，Nginx容器的镜像版本被设定为 nginx:1.21，并且定义了CPU和内存的请求与限制：

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod        # Pod的标识名，在名称空间中必须唯一
  namespace: default     # 该Pod所属的名称空间，省略时使用默认名称空间default
spec:
  containers:            # 定义容器，它是一个列表对象，可包括多个容器的定义，至少得有一个
  - name: nginx
    image: nginx:1.21    # 指定的 Nginx 版本 1.21
    resources:
      requests:
        memory: "64Mi"   # 请求的内存资源
        cpu: "250m"      # 请求的 CPU 资源 (250 毫核)
      limits:
        memory: "128Mi"  # 限制的最大内存资源
        cpu: "500m"      # 限制的最大 CPU 资源 (500 毫核)
    ports:
    - containerPort: 80   # 暴露 Nginx 的 80 端口

了解Pod运行状况

Kubectl get pods xxxx

打印Pod完整的资源规范

kubectl get pods NAME -o yaml|json

在这里插入图片描述
在这里插入图片描述

root@k8s-master01:~# kubectl get pods nginx-77b4fdf86c-925pk -o yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2024-10-13T05:28:15Z"
  generateName: nginx-77b4fdf86c-
  labels:
    app: nginx
    pod-template-hash: 77b4fdf86c
  name: nginx-77b4fdf86c-925pk
  namespace: default
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: nginx-77b4fdf86c
    uid: 02df6694-04bf-4aff-ae3c-d7db543305c8
  resourceVersion: "1131785"
  uid: 8bd4082a-8695-410b-b47f-c1459de202e2
spec:
  containers:
  - image: nginx
    imagePullPolicy: Always
    name: nginx
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-jxpbt
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: k8s-node01
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: kube-api-access-jxpbt
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2024-10-14T00:52:40Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2024-10-16T01:34:40Z"
    message: 'containers with unready status: [nginx]'
    reason: ContainersNotReady
    status: "False"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2024-10-16T01:34:40Z"
    message: 'containers with unready status: [nginx]'
    reason: ContainersNotReady
    status: "False"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2024-10-14T00:52:40Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - containerID: docker://1dd7ee9146c5704a0d4a6fc03e0297354f6ffe9e6b00ce387998e55462e35e73
    image: nginx:latest
    imageID: docker-pullable://nginx@sha256:d2eb56950b84efe34f966a2b92efb1a1a2ea53e7e93b94cdf45a27cf3cd47fc0
    lastState:
      terminated:
        containerID: docker://1dd7ee9146c5704a0d4a6fc03e0297354f6ffe9e6b00ce387998e55462e35e73
        exitCode: 255
        finishedAt: "2024-10-16T01:33:47Z"
        reason: Error
        startedAt: "2024-10-14T11:54:24Z"
    name: nginx
    ready: false
    restartCount: 0
    started: false
    state:
      waiting:
        message: Back-off pulling image "nginx"
        reason: ImagePullBackOff
  hostIP: 10.0.0.207
  phase: Running
  podIP: 10.244.1.73
  podIPs:
  - ip: 10.244.1.73
  qosClass: BestEffort
  startTime: "2024-10-14T00:52:40Z"

kubectl describe pods xxx

打印Pod资源的详细状态

kubectl describe TYPE NAME

在这里插入图片描述

kubectl logs -f|-p xxxx

在这里插入图片描述

Pod重启策略

在 Kubernetes 中，Pod 的重启策略（Restart Policy）决定了容器在失败或终止时是否以及如何重新启动。Kubernetes 提供了三种重启策略，用于控制 Pod 中容器的重启行为。每种策略适用于不同的使用场景和需求。

Pod的三种重启策略：
  1.Always(总是重启)       无论何种exit code，都要重启容器。持续运行的服务，自动重启崩溃的容器。
  
  2.OnFailure(失败时重启)  仅在exit code为非0值（即错误退出）时才重启容器。一次性任务，在任务失败时重启容器。
    
  3.Never(不重启)         无论何种exit code，都不重启容器。一次性任务，不重启容器。

1. Always

这是Kubernetes 中默认的重启策略，适用于长时间运行的服务应用，如web服务器、数据库等。如果容器在运行时崩溃、失败或者退出，Kubernetes 会 总是 尝试重启该容器。

Always
  适用场景：持续运行的服务或守护进程，如Nginx、MySQL等。
  
  行为：
    如果容器终止（无论退出码是成功或失败），都会自动重启容器。
    适合使用Deployment、DaemonSet等控制器来管理这些Pod，因为这些控制器会始终保持所需的副本数。

示例：Always 重启策略

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  restartPolicy: Always        # 重启策略为 Always
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

2. OnFailure

该策略适用于一次性任务，例如批处理或任务执行。这类容器通常会在完成任务后退出。如果任务执行失败（非 0 退出码），Kubernetes 会尝试重启容器。如果任务成功完成（0 退出码），容器不会重启。

OnFailure
  适用场景：适用于一次性任务或批处理任务，如数据导入、数据库备份等。可与Job控制器结合使用。
  
  行为：
    1.如果容器以非0状态码退出（表示任务失败），Kubernetes会重启容器。
    2.如果容器以0状态码退出（表示任务成功完成），Kubernetes不会重启容器。
    3.Job控制器可以管理OnFailure策略的Pod，保证任务在失败时能重试。

示例：OnFailure 重启策略

apiVersion: v1
kind: Pod
metadata:
  name: batch-pod
spec:
  restartPolicy: OnFailure           # 重启策略为OnFailure
  containers:
  - name: batch-job
    image: busybox
    command: ["sh", "-c", "exit 1"]  # 模拟失败退出

3. Never

这种策略用于只运行一次的任务或非常短暂的容器。无论容器是否失败或成功，Kubernetes 都不会重新启动它。

Never
  适用场景：适用于执行一次就退出的任务。比如，数据迁移任务、一次性脚本任务等。也可以与Job控制器搭配使用。
  
  行为：
    1.无论容器是成功（0 退出码）还是失败（非 0 退出码），都不会重新启动。
    2.适合那些只需要执行一次并完成的任务或临时性操作。

示例：Never 重启策略

apiVersion: v1
kind: Pod
metadata:
  name: one-shot-pod
spec:
  restartPolicy: Never               # 重启策略为 Never
  containers:
  - name: mytask
    image: busybox
    command: ["sh", "-c", "echo Task completed"]  # 打印任务完成信息

ImagePullPolicy

在 Kubernetes 中，Pod 的 imagePullPolicy 用于控制如何拉取容器镜像。它定义了 Kubernetes 在启动容器时是否应该拉取镜像，以及在什么条件下拉取镜像。Kubernetes 中有三种 imagePullPolicy 策略：

imagePullPolicy的三种取值：
  1.Always
     始终拉取镜像，无论节点上是否已经有该镜像。
     每次启动时都从仓库拉取镜像，适合使用 latest 或需要频繁更新的场景。

  2.IfNotPresent
     只有当节点上没有该镜像时才拉取。如果节点上已经有该镜像，则不会重新拉取。
     如果节点上没有镜像才拉取，适合明确版本号且希望节省资源的场景。

  3.Never
     不会从镜像仓库拉取镜像，容器只能使用节点上已有的镜像。如果节点上没有该镜像，Pod 将无法启动。
     永远不从仓库拉取，适合测试环境或手动管理镜像的场景。

1. Always

1.imagePullPolicy: Always
  当imagePullPolicy设置为Always时，Kubernetes每次创建或重新启动Pod时都会尝试从镜像仓库拉取镜像，
  即使节点上已经存在相同的镜像。

适用场景：
  1.使用未标记版本号的镜像标签（如 latest），因为最新的镜像可能发生变化，应该始终确保拉取最新的版本。
  2.你希望镜像在每次启动时保持更新。

示例：

apiVersion: v1
kind: Pod
metadata:
  name: always-pull-pod
spec:
  containers:
  - name: my-container
    image: myregistry.io/myapp:latest
    imagePullPolicy: Always

imagePullPolicy: Always 表示即使节点上已经存在 myregistry.io/myapp:latest 镜像，也会在每次启动时重新拉取该镜像。

2. IfNotPresent

2.imagePullPolicy: IfNotPresent
  当imagePullPolicy设置为IfNotPresent时，Kubernetes 仅在节点上没有该镜像时拉取。
  如果节点已经存在该镜像，则不会再去拉取。

适用场景：
  1.使用明确的镜像标签（如带有版本号的镜像：v1.0.0），且你确定节点上已有该版本的镜像。
  2.不希望频繁地拉取镜像来节省带宽和时间。

示例

apiVersion: v1
kind: Pod
metadata:
  name: if-not-present-pod
spec:
  containers:
  - name: my-container
    image: myregistry.io/myapp:v1.0.0
    imagePullPolicy: IfNotPresent

imagePullPolicy: IfNotPresent 表示如果节点上已经存在 myregistry.io/myapp:v1.0.0 镜像，Kubernetes 将不会再去拉取新镜像。

3. Never

3.imagePullPolicy: Never
  当imagePullPolicy设置为Never时，Kubernetes不会尝试从镜像仓库拉取镜像。它只能使用节点上已经存在的镜像。

适用场景：
  1.当你手动在节点上推送镜像时，或你不希望 Kubernetes 自动从外部镜像仓库拉取镜像。
  2.适合测试环境，手动控制镜像的管理。

示例

apiVersion: v1
kind: Pod
metadata:
  name: never-pull-pod
spec:
  containers:
  - name: my-container
    image: myregistry.io/myapp:v1.0.0
    imagePullPolicy: Never

imagePullPolicy: Never 表示 Kubernetes 将只使用节点上现有的镜像。如果节点上没有myregistry.io/myapp:v1.0.0 镜像，Pod 启动将失败。

部署wordPress

mysql

vim mysql.yaml

apiVersion: v1
kind: Pod
metadata:
  name: mysql
  namespace: default
spec:
  containers:
  - name: mysql
    image: mysql:8.0
    imagePullPolicy: IfNotPresent
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: lei.com
    - name: MYSQL_USER
      value: wpuser
    - name: MYSQL_PASSWORD
      value: wppass
    - name: MYSQL_DATABASE
      value: wordpress
  restartPolicy: OnFailure

kubectl apply -f mysql.yaml

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

kubectl exec -it msyql

执行以下命令可进入到mysql应用中

kubectl exec -it mysql -- /bin/sh

在这里插入图片描述

生成service

在这里插入图片描述

apiVersion: v1
kind: Namespace
metadata:
  name: blog
---
apiVersion: v1
kind: Pod
metadata:
  name: mysql
  labels:
    app: db
  namespace: blog
spec:
  containers:
  - name: mysql
    image: mysql:8.0
    imagePullPolicy: IfNotPresent
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: lei.com
    - name: MYSQL_USER
      value: wpuser
    - name: MYSQL_PASSWORD
      value: wppass
    - name: MYSQL_DATABASE
      value: wordpress
  restartPolicy: OnFailure
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: mysql
  name: mysql
  namespace: blog
spec:
  ports:
  - name: 3306-3306
    port: 3306
    protocol: TCP
    targetPort: 3306
  selector:
    app: db
  type: ClusterIP

在这里插入图片描述
在这里插入图片描述

wordPress

https://hub.docker.com/_/wordpress

追加service
在这里插入图片描述
vim wordpress.yaml

--
apiVersion: v1
kind: Pod
metadata:
  name: wordpress
  namespace: blog
  labels:
    app: wordpress
spec:
  containers:
  - name: wordpress
    image: wordpress:6
    env:
    - name: WORDPRESS_DB_HOST
      value: mysql
    - name: WORDPRESS_DB_NAME
      value: wordpress
    - name: WORDPRESS_DB_USER
      value: wpuser
    - name: WORDPRESS_DB_PASSWORD
      value: wppass
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: wordpress
  name: wordpress
  namespace: blog
spec:
  ports:
  - name: 80-80
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: wordpress
  type: LoadBalancer

在这里插入图片描述
在这里插入图片描述

配置Nginx清单

vim nginx-pod.yaml

apiVersion: v1        #api文档版本
kind: Pod             #资源对象类型，也可以配置为像Deployment、StatefulSet这一类的对象
metadata:             #Pod相关的元数据，用于描述Pod 的数据
  name: nginx-demo    #Pod 的名称
  labels:             #定义 Pod 的标签
    type: app         #自定义 label标签，名字为type，值为app
    test: 1.0.0       #自定义label标签，描述Pod版本号
  namespace: 'default'  #命名空间的配置
spec:                  #期望Pod按照这里面的描述进行创建
  containers:          #对于Pod中的容器描述
  - name: nginx        #容器的名称
    image: nginx:latest #指定容器的镜像
    imagePullPolicy: IfNotPresent  #镜像拉取策略，指定如果本地有就用本地的，如果没有就拉取远程的
    command :          # 指定容器启动时执行的命令
    - nginx
    - -g
    - 'daemon off;'   # nginx -g 'daemon off; '
    workingDir: /usr/share/nginx/html  #定义容器启动后的工作目录
    ports:
    - name: http         #端口名称
      containerPort: 80  #描述容器内要暴露什么端口
      protocol: TCP      #描述该端口是基于哪种协议通信的- 
    env:              #坏境变量
    - name: JVM_OPTS     #环境变量名称
      value: '-Xms128m -Xmx128m'  #环境变量的值
    resources:
      requests:             #最少需要多少资源
        cpu: 100m           #限制cpu最少使用0.1个核心
        memory: 128Mi       #限制内存最少使用128兆
      limits:               #最多可以用多少资源
        cpu: 200m           #|限制cpu最多使用0.2个核心
        memory: 256Mi          #限制最多使用256兆
  restartPolicy: OnFailure   #重启策略，只有失败的情况才会重启

这是允许 Docker 的网络端口后，拉取最成功的一次：

sudo ufw allow 443/tcp
sudo ufw allow 80/tcp

在这里插入图片描述

root@k8s-master01:/data/pods# kubectl describe pod nginx-demo
Name:             nginx-demo
Namespace:        default
Priority:         0
Service Account:  default
Node:             k8s-node01/10.0.0.207
Start Time:       Sun, 20 Oct 2024 19:48:32 +0800
Labels:           test=1.0.0
                  type=app
Annotations:      <none>
Status:           Running
IP:               10.244.1.97
IPs:
  IP:  10.244.1.97
Containers:
  nginx:
    Container ID:  docker://e4713a1e3ecdd09a190e45243f1866d0f313fc5b155c15bbf3633c5633686fd2
    Image:         nginx:latest
    Image ID:      docker-pullable://nginx@sha256:28402db69fec7c17e179ea87882667f1e054391138f77ffaf0c3eb388efc3ffb
    Port:          80/TCP
    Host Port:     0/TCP
    Command:
      nginx
      -g
      daemon off;
    State:          Running
      Started:      Sun, 20 Oct 2024 19:48:33 +0800
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     200m
      memory:  256Mi
    Requests:
      cpu:     100m
      memory:  128Mi
    Environment:
      JVM_OPTS:  -Xms128m -Xmx128m
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-sfb69 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  kube-api-access-sfb69:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  15m   default-scheduler  Successfully assigned default/nginx-demo to k8s-node01
  Normal  Pulled     15m   kubelet            Container image "nginx:latest" already present on machine
  Normal  Created    15m   kubelet            Created container nginx
  Normal  Started    15m   kubelet            Started container nginx

在这里插入图片描述

Pod探针

容器式运行的应用类似于“黑盒”，为了便于平台对其进行监测，云原生应用应该输出用于监视自身的API。于是Pod探针就孕育而生。

Kubernetes 中的探针机制（Probes）用于定期检查 Pod 内容器的健康状态，并做出相应的处理。探针有助于确保应用的可用性、容器的健康和服务的稳定性。

简单来说Pod探针就是Pod内的监控机制，用来监控Pod 内容器的健康状态，从而保证Pod的正常运行。

思考：为什么重启策略能够帮助我们重启Pod从而实现故障自愈?

探针类型

探针机制主要包括三种类型：
  1.Liveness Probe（存活探针）
  2.Readiness Probe（就绪探针）
  3.Startup Probe（启动探针）
1.Liveness Probe
Liveness Probe（存活探针）
  作用：
    1.检查容器是否处于健康状态（存活）。如果探针失败，Kubernetes会重启容器。
    2.使用场景：例如，服务出现死锁、无法恢复，或者容器卡住但没有退出。

  工作原理：
    1.Kubernetes 定期对容器进行检查，如果探针报告失败，则认为容器已经“挂掉”，并根据Pod的重启策略进行处理。
    2.存活探针通常与容器内部健康状态相关。例如应用服务的健康检查接口/health，如果返回错误则表示服务已不可用。

配置示例：

livenessProbe:
  httpGet:
    path: /healthz          # 应用提供的健康检查接口
    port: 8080              # 运行服务的端口
  initialDelaySeconds: 10   # 容器启动后多少秒开始检查
  periodSeconds: 5          # 每隔几秒进行一次检查

# initialDelaySeconds：容器启动后等待多长时间开始第一次检查。
# periodSeconds：每隔几秒进行一次检查。
# httpGet：通过HTTP请求执行探测，路径/healthz，端口8080。
httpGet

nginx-LinvessProbe.yaml
在这里插入图片描述

在这里插入图片描述
started2.html不存在，所以Liveness probe失败了，我设置的是探测三次失败才是真的失败，所以我快速创建started2.html页面，当它探测第二次时，该页面存在就成功重启了pod
在这里插入图片描述

2.Readiness Probe
Readiness Probe（就绪探针）
  作用：
    1.检查容器是否已经准备好接收流量。
    2.使用场景：用于确定应用是否已经启动并能够正常提供服务。当应用还没有准备好时，Kubernetes不会将流量路由到该容器。

  工作原理：
    1.Readiness Probe的失败不会导致容器重启，但会使容器从服务（Service）的负载均衡中移除。
      也就是说，当探针检测到容器未准备好时，集群中的其他组件不会向该容器发送流量。
    2.容器一旦准备好，探针会成功，Kubernetes 会将其重新加入到流量调度中。

配置示例：

readinessProbe:
  tcpSocket:
    port: 3306            # 检测应用监听的 TCP 端口是否开放
  initialDelaySeconds: 5  # 容器启动后等待多少秒开始检查
  periodSeconds: 10       # 每隔几秒检查一次

#tcpSocket：通过 TCP 连接检测容器是否准备好接受请求，通常用于数据库等 TCP 服务。
#initialDelaySeconds 和 periodSeconds 的配置与 Liveness Probe 类似。
httpGet

在这里插入图片描述
started3.html不存在，所以Readiness prode失败，此时快速创建该页面，就能在到达重启次数最大阈值时，保证pod的重启成功。
在这里插入图片描述

3.Startup Probe

当配置了startup Probe后，会先禁用其他探针，直到startup Probe成功后，其他探针才会继续。

Startup Probe（启动探针）
  作用：
    1.用于检测应用是否成功启动。
    2.使用场景：启动缓慢的应用可能需要较长时间初始化。如果在应用启动期间立即执行存活探针检查，
      容器可能会被错误地杀死。Startup Probe专门用于检测容器是否已成功启动，避免启动过程中的误判。
      
  工作原理：
    1.Startup Probe是在容器启动期间检测应用是否已经启动完成。
    2.一旦Startup Probe成功，Kubernetes就会停止它，并开始执行Liveness Probe和Readiness Probe。
    3.如果Startup Probe失败，Kubernetes会重新启动容器。

配置示例：

startupProbe:
  exec:
    command:
    - cat
    - /tmp/healthy         # 检查是否存在某个文件来确定服务启动成功
  initialDelaySeconds: 10  # 等待时间
  periodSeconds: 5         # 每隔几秒执行一次检查
  failureThreshold: 30     # 允许探测失败的次数

#exec：通过在容器内执行命令来探测，例如检查文件/tmp/healthy是否存在。
#failureThreshold：如果探测失败超过30次，Kubernetes认为启动失败，重启容器。
httpGet

vim nginx-StartupProbe.yaml
在这里插入图片描述
在这里插入图片描述
下图提示，Startup probe失败，返回了404
在这里插入图片描述
此时我们get pod可以看到 nginx-startup这个pod的状态已经Completed了，且restarts了4次
在这里插入图片描述
我们再将启动探针请求的路径改为一个存在的页面/index.html
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

tcpSocket

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

exec

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
exec的命令执行成功了。
在这里插入图片描述

探针的三种探测方式

Kubernetes支持三种探测方式来执行探针检查：
  1.Exec探测：根据指定命令的结果状态码判定
  2.TcpSocket探测：根据相应TCP套接字连接建立状态判定
  3.HTTPGet探测：根据指定https/http服务URL的响应结果判定

HTTP请求探测

HTTP请求探测（httpGet）
  1.Kubernetes通过发起HTTP请求检测应用的健康状态。
  2.适用于提供REST API的应用。

配置示例
  httpGet:
    path: /healthz  # 应用的健康检查接口
    port: 8080      # 检测的端口号

TCP Socket探测

TCP Socket探测（tcpSocket）
  Kubernetes通过尝试连接到容器上的指定TCP端口，来检测应用是否健康。
  常用于数据库或其他基于TCP服务的检测。

配置示例
  tcpSocket:
    port: 3306  # 检查MySQL的端口是否打开

命令执行探测

命令执行探测（exec）
  1.Kubernetes在容器内执行指定的命令，并根据其返回值判断健康状态。
    如果命令返回0，表示探测成功；如果返回非0，表示探测失败。
  2.适用于需要通过内部命令检查容器状态的应用。

配置示例
  exec:
    command:
    - cat
    - /tmp/healthy  # 通过检查容器内的文件是否存在判断健康状态

探针工作流程

探针机制的工作流程
  1.探针配置和执行：
    1.每个探针配置都可以设置探测开始时间、间隔、失败或成功阈值等。
    2.Kubernetes根据探针类型和探测方式定期执行健康检查。
    
  2.健康检查结果：
    1.Liveness Probe失败时，Kubernetes会杀死容器，Pod中的容器将会被重启。
    2.Readiness Probe失败时，Kubernetes不会杀死容器，但会将容器从服务的流量路由中移除，直到探测恢复为止。
    3.Startup Probe失败时，Kubernetes会重启容器，避免容器在初始化阶段被错误判断为不健康。
    
  3.容器状态的更新：
    1.探测成功时，Kubernetes将相应地更新容器的状态，确保其是否可用或存活。

配置探针参数

探针可以通过多个配置参数来控制其行为，包括：
  1.initialDelaySeconds：容器启动后首次执行探针前的等待时间。
  2.periodSeconds：探针之间的间隔时间。
  3.timeoutSeconds：探针超时时间。
  4.successThreshold：在判断容器恢复前，探针必须连续成功的次数。
  5.failureThreshold：在判断容器失败前，探针必须连续失败的次数。

探针示例

以下是一个包含 Liveness、Readiness 和 Startup Probe 的 Pod 配置示例：

apiVersion: v1
kind: Pod
metadata:
  name: probe-example
spec:
  containers:
  - name: my-app
    image: my-app:latest
    ports:
    - containerPort: 8080
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
    startupProbe:
      httpGet:
        path: /startup
        port: 8080
      initialDelaySeconds: 0
      periodSeconds: 10
      failureThreshold: 30
配置说明：
配置说明：
  1.livenessProbe：
      通过 HTTP GET 请求 /healthz 路径，探测端口为 8080。
      探针初始延迟 10 秒，之后每 5 秒进行一次健康检查。
      
  2.readinessProbe：
      通过 HTTP GET 请求 /ready 路径，探测端口为 8080。
      探针初始延迟 5 秒，之后每 5 秒进行一次检查，确保应用准备好接收请求。
  
  3.startupProbe：
      通过 HTTP GET 请求 /startup 路径，探测端口为 8080。
      立即开始探测，每 10 秒探测一次，最多尝试 30 次（即 5 分钟），用于检测应用是否启动成功。
探针实际应用场景
实际应用场景
  1.Liveness Probe： 
      在微服务应用中，如果某个服务线程发生死锁，导致请求无法处理，但容器进程仍然存活，
      此时 Liveness 探针可以及时发现并重启该容器。

  2.Readiness Probe： 
      当应用程序需要加载大量配置或初始化连接池时，在这个期间可能不希望接收外部请求。
      Readiness Probe 可以用于在应用程序完全准备好处理请求后再将流量引导到该实例。

  3.Startup Probe： 
      启动时间较长的应用程序（例如大型 Java 应用）可以使用 Startup Probe 进行健康检查，
      避免因启动时间过长而被 Liveness Probe 误判为不健康。

资源需求和限制

在 Kubernetes 中，Pod 的资源需求和限制机制用于管理 Pod 使用的计算资源，如 CPU 和内存。这是为了确保集群中的资源被合理分配，并防止某些 Pod 过度使用资源，影响其他 Pod 的运行。

资源需求和资源限制
  ◼资源需求（requests）
    ◆定义需要系统预留给该容器使用的资源最小可用值
    ◆容器运行时可能用不到这些额度的资源，但用到时必须确保有相应数量的资源可用
    ◆资源需求的定义会影响调度器的决策
    
  ◼资源限制（limits）
    ◆定义该容器可以申请使用的资源最大可用值，超出该额度的资源使用请求将被拒绝
    ◆该限制需要大于等于requests的值，但系统在其某项资源紧张时，会从容器那里回收其使用的超出其requests值的那部分

requests和limits定义在容器级别，主要围绕cpu、memory和hugepages三种资源

示例：配置 CPU 和内存的请求和限制

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      requests:
        memory: "64Mi"    # 最少请求 64 MiB 内存
        cpu: "250m"       # 最少请求 0.25 个 CPU
      limits:
        memory: "128Mi"   # 最多允许使用 128 MiB 内存
        cpu: "500m"       # 最多允许使用 0.5 个 CPU

在该示例中：
  1.requests.memory 设置为64Mi，表示容器至少需要64MiB内存，才能正常运行。
    Kubernetes Scheduler会保证在调度Pod时，节点上至少有64MiB的内存可用。
    
  2.requests.cpu 设置为250m（即0.25 核），表示容器至少需要0.25个CPU核心。
  
  3.limits.memory 设置为128Mi，表示容器最多可以使用128 MiB的内存。
    如果容器使用的内存超出128 MiB，则可能会被Kubernetes强制终止。
    
  4.limits.cpu 设置为500m（即 0.5 核），表示容器最多可以使用0.5个CPU 核心，超过这个值将会受到限制。

资源超出限制的行为

当容器使用的资源超过其配置的限制时，Kubernetes 会有以下行为：
  1.超出CPU限制：
      Kubernetes 不会杀死容器，但会对其 CPU 使用进行限制，导致容器无法使用超出限制的 CPU 资源。
      这会导致容器的性能下降，但不会直接终止容器。

  2.超出内存限制：
      如果容器使用的内存超出了其限制，Kubernetes 会将该容器标记为内存超限（Out of Memory, OOM），并强制杀死容器。
      这种情况下，Pod 的状态会变为 OOMKilled，容器会被重新启动。

Pod设计模式

Kubernetes容器设计模式的分类
  容器设计模式大致可以分为以下几类：
   1.单容器Pod模式（Single Container Pod Pattern）
   2.多容器Pod模式（Multi-container Pod Pattern）
   3.Sidecar模式
   4.Ambassador模式
   5.Adapter模式
   6.Init容器模式
   7.Daemon模式
   8.Job模式

多容器Pod

在这个模式中，一个 Pod 中包含多个容器，这些容器相互协作，共享 Pod 的网络和存储卷。这种模式通常用于需要紧密耦合的场景，每个容器都完成不同的任务，但它们之间需要共享某些资源。

多容器Pod模式
  1.使用场景：需要多个紧密耦合的容器共同工作，如一个容器处理主应用，另一个容器用于日志、代理、监控等辅助任务。
  2.优点：容器可以共享资源并紧密协作。
  3.缺点：调度时会整体调度，耦合度较高。

示例：多容器 Pod

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: app-container
    image: myapp
    ports:
    - containerPort: 8080
  - name: logger-container
    image: logger
    command: ["sh", "-c", "tail -f /var/log/app.log"]
    volumeMounts:
    - name: log-volume
      mountPath: /var/log
  volumes:
  - name: log-volume
    emptyDir: {}

在这个示例中，multi-container-pod 中包含两个容器：
  app-container负责运行主应用。
  logger-container负责日志记录。两个容器共享log-volume，以协作处理日志文件。

Pod状态及异常

诊断流程
在这里插入图片描述

常见状态及含义

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

Pod 相位与容器状态

在Kubernetes中，Pod 是最小的调度单位。每个 Pod 有自己的生命周期，包含多个不同的相位（Phase），这些相位描述了 Pod 从创建到终止的整个过程。理解这些相位有助于监控和管理 Pod 的状态，特别是在排查问题时。

Pod 相位概览
  1.Pending（挂起）
  2.Running（运行中）
  3.Succeeded（成功）
  4.Failed（失败）
  5.Unknown（未知）

Pod生命周期

官方帮助手册：https://v1-27.docs.kubernetes.io/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/

Kubernetes Pod 的生命周期包含多个阶段，从创建到删除。每个 Pod 都有明确的生命周期，Kubernetes 通过 Pod 状态来反映这个生命周期。

Kubernetes Pod 的生命周期从 Pending 开始，经过 Running，并可能结束于 Succeeded 或 Failed，中间可能会出现如 CrashLoopBackOff 或 Evicted 等状态。不同阶段表示 Kubernetes 在处理 Pod 的不同状态。

1. Pending (挂起)

这是 Pod 创建后的第一个状态，表示 Pod 已被 Kubernetes API Server 接收并且已经通过了调度（Scheduler）的处理，但某些条件还没有满足，因此尚未启动所有容器。

进入 Pending 状态的可能原因：
  1.Kubernetes 正在为 Pod 寻找合适的节点来运行它（调度阶段）。
  2.Pod 的镜像正在从镜像仓库中拉取，或者下载镜像遇到延迟。
  3.等待卷（如 PersistentVolume）的创建或挂载。

举例：
你创建了一个 Pod，但是由于没有可用的节点或网络问题，Pod 资源（如 Volume）还未准备好，Pod 会一直处于 Pending 状态。

当资源就绪且调度成功，Pod 状态会从 Pending 转为下一个阶段。

2. ContainerCreating 创建中

Pod 在调度到某个节点后，会开始启动容器。在启动期间，Pod 进入 ContainerCreating 状态，这意味着 Kubernetes 正在为容器设置所需的文件系统、网络等。

举例：
Pod 已经找到运行的节点，正在进行容器初始化，可能是下载镜像或配置网络等。在镜像拉取完成后，状态会进入 Running。

3. Running 运行中

当 Pod 成功调度到节点并且所有指定的容器至少启动了一个时，它就会进入 Running 状态。

进入 Running 状态的条件：
  1.Pod 已经成功调度到某个节点上。
  2.Pod 中的至少一个容器正在运行，或者已经成功启动并运行。
  3.Pod 所需的资源（如 CPU、内存、存储卷）已经分配并挂载。

举例：

一个运行中的 Nginx 服务 Pod 正在接受 HTTP 请求，且状态为 Running。

kubectl get pods
NAME         READY   STATUS    RESTARTS   AGE
example-pod  1/1     Running   0          5m

即使 Pod 进入 Running 状态，这并不意味着所有容器都在正常工作。例如，一个或多个容器可能正在不断地崩溃（CrashLoopBackOff），尽管 Pod 仍显示为 Running。

4. Succeeded 成功

如果 Pod 中的容器（通常是一次性任务，如批处理作业）成功完成并退出，则 Pod 的状态变为 Succeeded。

所有容器都正常退出（Exit Code 0）。
这种状态通常出现在 Job 类型的资源中，代表任务成功完成。

举例：

一个完成备份任务的 Pod 成功运行完所有操作，进入 Succeeded 状态。

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  template:
    spec:
      containers:
      - name: backup-container
        image: backup-image
      restartPolicy: Never

当 Pod 中的所有容器正常结束且没有发生错误（即它们退出状态码为 0）时，Pod 会进入 Succeeded 状态。这个状态通常出现在运行一次性任务（例如批处理作业）的 Pod 中。

5. Failed 状态

当 Pod 中的某个容器异常退出（即退出状态码非 0）且不会被重启时，Pod 会进入 Failed 状态。Pod 也可能因无法拉取镜像或其他问题进入 Failed 状态。

一个或多个容器非正常退出，且不再重启。

举例：

假设一个 Pod 运行了错误的命令，导致容器意外退出，状态会变为 Failed。

kubectl get pods
NAME         READY   STATUS   RESTARTS   AGE
failed-pod   0/1     Failed   0          10m

6. CrashLoopBackOff 状态

如果容器由于错误反复崩溃并尝试重启，Pod 会进入 CrashLoopBackOff 状态。

容器崩溃后 Kubernetes 会根据策略尝试重启，但如果重启失败次数过多，Pod 状态会变为 CrashLoopBackOff。

举例：

一个 Pod 启动时因配置文件缺失持续崩溃，状态为 CrashLoopBackOff，Kubernetes 会自动重试重启。

kubectl get pods
NAME            READY   STATUS              RESTARTS   AGE
crashing-pod    0/1     CrashLoopBackOff    5          15m

7. Terminating 状态

当你删除 Pod 时，Pod 进入 Terminating 状态。此时，Kubernetes 会执行以下操作：

发送信号给容器，让它优雅退出。
清理容器资源（如网络、存储）。

举例：

你执行 kubectl delete pod example-pod，Pod 会先进入 Terminating 状态，等待容器完全终止后，再从集群中移除。

kubectl delete pod example-pod
kubectl get pods
NAME         READY   STATUS        RESTARTS   AGE
example-pod  0/1     Terminating   0          2m

8. Evicted 状态

在某些情况下，节点资源不足或由于其他策略（如节点故障或预留资源），Pod 会被驱逐，状态为 Evicted。此时 Pod 不会再运行。

举例：

当一个节点的资源不足时，Kubernetes 可能会将低优先级的 Pod 驱逐，状态显示为 Evicted。

kubectl get pods
NAME           READY   STATUS    RESTARTS   AGE
evicted-pod    0/1     Evicted   0          20m

9. Unknown（未知）

当 Kubernetes 无法获取 Pod 的状态信息时，Pod 会被标记为 Unknown 状态。通常这是由于网络连接问题或与节点通信中断引起的。

进入 Unknown 状态的可能原因：
   1.控制平面无法与节点通信，可能是节点挂了，或者网络故障导致了状态无法上报。

Pod 相位与容器状态的区别

Pod 相位与容器状态的区别
  1.Pod 相位（Pod Phase）：描述 Pod 的整体状态，它是一种高层次的状态描述，通常用于标识 Pod 在整个生命周期的哪个阶段。
  
  2.容器状态（Container State）：Pod 内部的每个容器都有自己的状态，详细说明了容器是否正在运行、已退出或等待启动。
      容器状态包括：
         Waiting（等待中）：容器还没有启动，可能正在拉取镜像或等待资源。
         Running（运行中）：容器正在正常运行。
         Terminated（已终止）：容器已停止，可能是正常退出（状态码为 0）或者异常退出。

举例：一个Pod可能处于Running状态，但其中一个容器可能由于崩溃正在不断重启，这时该容器的状态可能为CrashLoopBackOff，而整个Pod仍然显示为Running。

总结
  1.Pending：Pod 已被 Kubernetes 接收，但还没有开始所有容器。
  2.Running：Pod 已被调度到节点，且至少有一个容器在运行。
  3.Succeeded：Pod 中的所有容器都成功结束。
  4.Failed：Pod 中某个容器异常终止，且不会再重启。
  5.Unknown：Kubernetes 无法获取 Pod 的状态，可能是由于节点通信中断。

理解这些相位有助于在 Kubernetes 中监控和调试 Pod 的状态，并及时采取措施处理异常问题。

评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值