Kubernetes--深入理解Pod资源管理
文章目录
- kubectl --help
- api-resources
- api-versions
- kubectl explain ...
- API资源
- 资源规范
- Pod
- Service
- ConfigMap
- Secret
- 显示资源
- 删除资源
- 详细描述
- RESTful API
- Pod资源管理
- Pod的核心概念
- Pod资源配置
- 了解Pod运行状况
- Kubectl get pods xxxx
- kubectl describe pods xxx
- kubectl logs -f|-p xxxx
- Pod重启策略
- 1. Always
- 2. OnFailure
- 3. Never
- ImagePullPolicy
- 1. Always
- 2. IfNotPresent
- 3. Never
- 部署wordPress
- mysql
- kubectl exec -it msyql
- 生成service
- wordPress
- Pod探针
- 探针类型
- 1.Liveness Probe
- 2.Readiness Probe
- 3.Startup Probe
- 探针的三种探测方式
- 探针工作流程
- 资源需求和限制
- Pod设计模式
- 多容器Pod
- Pod状态及异常
- 常见状态及含义
- Pod生命周期
- 1. Pending 状态
- 2. ContainerCreating 状态
- 3. Running 状态
- 4. Succeeded 状态
- 5. Failed 状态
- 6. CrashLoopBackOff 状态
- 7. Terminating 状态
- 8. Evicted 状态
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状态及异常
诊断流程
常见状态及含义
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-container
image: backup-image
restartPolicy: 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