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 stdinexpose          Take a replication controller, service, deployment or pod and expose it as a new Kubernetes servicerun             Run a particular image on the clusterset             Set specific features on objectsBasic Commands (Intermediate):explain         Get documentation for a resourceget             Display one or many resourcesedit            Edit a resource on the serverdelete          Delete resources by file names, stdin, resources and names, or by resources and label selectorDeploy Commands:rollout         Manage the rollout of a resourcescale           Set a new size for a deployment, replica set, or replication controllerautoscale       Auto-scale a deployment, replica set, stateful set, or replication controllerCluster Management Commands:certificate     Modify certificate resources.cluster-info    Display cluster informationtop             Display resource (CPU/memory) usagecordon          Mark node as unschedulableuncordon        Mark node as schedulabledrain           Drain node in preparation for maintenancetaint           Update the taints on one or more nodesTroubleshooting and Debugging Commands:describe        Show details of a specific resource or group of resourceslogs            Print the logs for a container in a podattach          Attach to a running containerexec            Execute a command in a containerport-forward    Forward one or more local ports to a podproxy           Run a proxy to the Kubernetes API servercp              Copy files and directories to and from containersauth            Inspect authorizationdebug           Create debugging sessions for troubleshooting workloads and nodesevents          List eventsAdvanced Commands:diff            Diff the live version against a would-be applied versionapply           Apply a configuration to a resource by file name or stdinpatch           Update fields of a resourcereplace         Replace a resource by file name or stdinwait            Experimental: Wait for a specific condition on one or many resourceskustomize       Build a kustomization target from a directory or URLSettings Commands:label           Update the labels on a resourceannotate        Update the annotations on a resourcecompletion      Output shell completion code for the specified shell (bash, zsh, fish, or powershell)Other Commands:api-resources   Print the supported API resources on the serverapi-versions    Print the supported API versions on the server, in the form of "group/version"config          Modify kubeconfig filesplugin          Provides utilities for interacting with pluginsversion         Print the client and server version informationUsage: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/v2alpha12.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:    v1FIELD: spec <DeploymentSpec>DESCRIPTION:Specification of the desired behavior of the Deployment.DeploymentSpec is the specification of the desired behavior of theDeployment.FIELDS:minReadySeconds	<integer>Minimum number of seconds for which a newly created pod should be readywithout 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 isconsidered to be failed. The deployment controller will continue to processfailed deployments and a condition with a ProgressDeadlineExceeded reasonwill be surfaced in the deployment status. Note that progress will not beestimated during the time a deployment is paused. Defaults to 600s.replicas	<integer>Number of desired pods. This is a pointer to distinguish between explicitzero and not specified. Defaults to 1.revisionHistoryLimit	<integer>The number of old ReplicaSets to retain to allow rollback. This is a pointerto distinguish between explicit zero and not specified. Defaults to 10.selector	<LabelSelector> -required-Label selector for pods. Existing ReplicaSets whose pods are selected bythis will be the ones affected by this deployment. It must match the podtemplate'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 allowedtemplate.spec.restartPolicy value is "Always".

API资源

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

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

API: RESTful APIResourceDeployment --> demoapp --> Controller执行Service资源类型 --> 对象 --> 实体对象：用户期望的状态 实体：实际状态 小汽车：资源类型发动机：变速箱

资源规范

Pod

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

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

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

Service

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

apiVersion: v1
kind: Service
metadata:name: myservice
spec:selector:app: myappports:- protocol: TCPport: 80targetPort: 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：   资源对象管理的基本操作：CRUDCreateReadUpdateDeleteCreate:kubectl createRead:kubectl get/describeUpdate: kubectl edit/patch/replace/setDelete:kubectl deleteHTTP协议method：GETPOSTPUTDELETEOPTIONS...  

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: nginximage: nginx:1.21    # 指定的 Nginx 版本 1.21resources: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        # 重启策略为 Alwayscontainers:- name: nginximage: nginxports:- 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           # 重启策略为OnFailurecontainers:- name: batch-jobimage: busyboxcommand: ["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               # 重启策略为 Nevercontainers:- name: mytaskimage: busyboxcommand: ["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-containerimage: myregistry.io/myapp:latestimagePullPolicy: 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-containerimage: myregistry.io/myapp:v1.0.0imagePullPolicy: 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-containerimage: myregistry.io/myapp:v1.0.0imagePullPolicy: Never

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

部署wordPress

mysql

vim mysql.yaml

apiVersion: v1
kind: Pod
metadata:name: mysqlnamespace: default
spec:containers:- name: mysqlimage: mysql:8.0imagePullPolicy: IfNotPresentenv:- name: MYSQL_ROOT_PASSWORDvalue: lei.com- name: MYSQL_USERvalue: wpuser- name: MYSQL_PASSWORDvalue: wppass- name: MYSQL_DATABASEvalue: wordpressrestartPolicy: 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: mysqllabels:app: dbnamespace: blog
spec:containers:- name: mysqlimage: mysql:8.0imagePullPolicy: IfNotPresentenv:- name: MYSQL_ROOT_PASSWORDvalue: lei.com- name: MYSQL_USERvalue: wpuser- name: MYSQL_PASSWORDvalue: wppass- name: MYSQL_DATABASEvalue: wordpressrestartPolicy: OnFailure
---
apiVersion: v1
kind: Service
metadata:labels:app: mysqlname: mysqlnamespace: blog
spec:ports:- name: 3306-3306port: 3306protocol: TCPtargetPort: 3306selector:app: dbtype: ClusterIP

wordPress

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

追加service

vim wordpress.yaml

--
apiVersion: v1
kind: Pod
metadata:name: wordpressnamespace: bloglabels:app: wordpress
spec:containers:- name: wordpressimage: wordpress:6env:- name: WORDPRESS_DB_HOSTvalue: mysql- name: WORDPRESS_DB_NAMEvalue: wordpress- name: WORDPRESS_DB_USERvalue: wpuser- name: WORDPRESS_DB_PASSWORDvalue: wppass
---
apiVersion: v1
kind: Service
metadata:labels:app: wordpressname: wordpressnamespace: blog
spec:ports:- name: 80-80port: 80protocol: TCPtargetPort: 80selector:app: wordpresstype: 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: nginximage: nginxresources:requests:memory: "64Mi"    # 最少请求 64 MiB 内存cpu: "250m"       # 最少请求 0.25 个 CPUlimits: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-containerimage: myappports:- containerPort: 8080- name: logger-containerimage: loggercommand: ["sh", "-c", "tail -f /var/log/app.log"]volumeMounts:- name: log-volumemountPath: /var/logvolumes:- name: log-volumeemptyDir: {}在这个示例中，multi-container-pod 中包含两个容器：app-container负责运行主应用。logger-container负责日志记录。两个容器共享log-volume，以协作处理日志文件。

Pod状态及异常

诊断流程

常见状态及含义

Pod生命周期

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

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

1. Pending 状态

当一个 Pod 被创建后，它首先会进入 Pending 状态。此状态表示 Pod 已被 Kubernetes 接收，但还没有启动容器。

这个阶段涉及以下操作：1.调度器（Scheduler）为 Pod 分配节点。2.Pod 的 Volume 等资源在节点上创建。

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

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

2. ContainerCreating 状态

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

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

3. Running 状态

当 Pod 中的所有容器成功启动并运行，Pod 就进入了 Running 状态。

容器已经被创建并在运行中。
在 Running 状态下，Pod 可能仍然进行一些初始化步骤（如 init 容器）。

举例：

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

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

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-containerimage: backup-imagerestartPolicy: Never

5. Failed 状态

当 Pod 中的容器在运行时发生错误并终止（Exit Code 非0），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