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=

显示资源

显示资源：
  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的可用性。

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

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

Pod探针

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

Kubernetes 中的探针机制（Probes）用于定期检查 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。

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 类似。

3.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认为启动失败，重启容器。

探针的三种探测方式

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将相应地更新容器的状态，确保其是否可用或存活。

资源需求和限制

在 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状态及异常

诊断流程

常见状态及含义