《Kubernetes 资源与 Pod 全攻略：从基础概念到实战部署，小白也能轻松上手》

最新推荐文章于 2026-06-24 21:03:58 发布
原创 最新推荐文章于 2026-06-24 21:03:58 发布 · 984 阅读 · 24 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测
标签
#kubernetes #容器 #云原生 #Pod

kubernetes 中的资源

1. 资源管理介绍

  • 在kubernetes中，所有的内容都抽象为资源，用户需要通过操作资源来管理kubernetes。
  • kubernetes的本质上就是一个集群系统，用户可以在集群中部署各种服务
  • 所谓的部署服务，其实就是在kubernetes集群中运行一个个的容器，并将指定的程序跑在容器中。
  • kubernetes的最小管理单元是pod而不是容器，只能将容器放在Pod中，
  • kubernetes一般也不会直接管理Pod，而是通过Pod控制器来管理Pod的。
  • Pod中服务的访问是由kubernetes提供的Service资源来实现。
  • Pod中程序的数据需要持久化是由kubernetes提供的各种存储系统来实现
资源分类资源名称缩写资源作用
集群级别资源nodesno集群组成部分
集群级别资源namespacesns隔离Pod
Pod资源podspo装载容器
Pod资源控制器replicationcontrollersrc控制Pod资源
Pod资源控制器replicasetsrs控制Pod资源
Pod资源控制器deploymentsds控制Pod资源
Pod资源控制器daemonsetsrs控制Pod资源
Pod资源控制器jobs控制Pod资源
Pod资源控制器cronjobscj控制Pod资源
Pod资源控制器horizontalpodautoscalershpa控制Pod资源
Pod资源控制器statefulsetssts控制Pod资源
服务发现资源servicessvc统一Pod对外接口
服务发现资源ingressing统一Pod对外接口
存储资源volumeattachments存储
存储资源persistenvolumeclaimspv存储
存储资源persistentvolumeclaimspvc存储
配置资源configmapscm配置
配置资源secrets配置

2. 资源管理方式

  • 命令式对象管理：直接使用命令去操作kubernetes资源

    kubectl run nginx-pod --image=nginx:latest --port=80

  • 命令式对象配置：通过命令配置和配置文件去操作kubernetes资源

    kubectl create/patch -f nginx-pod.yaml

  • 声明式对象配置：通过apply命令和配置文件去操作kubernetes资源

    kubectl apply -f nginx-pod.yaml

命令式对象管理测试简单只能操作活动对象，无法审计、跟踪
命令式对象配置开发可以审计、跟踪项目大时，配置文件多，操作麻烦
类型适用环境优点缺点
声明式对象配置开发支持目录操作意外情况下难以调试

2.1 命令时对象管理

kubectl是kubernetes集群的命令行工具，通过它能够对集群本身进行管理，并能够在集群上进行容器化应用的安装部署

kubectl命令的语法如下：

kubectl [command] [type] [name] [flags]

comand：指定要对资源执行的操作，例如create、get、delete

type：指定资源类型，比如deployment、pod、service

name：指定资源的名称，名称大小写敏感

flags：指定额外的可选参数

#查看所有pod
[root@master ~]# kubectl get pods
NAME                             READY   STATUS      RESTARTS   AGE
cronjob-example-29346320-jqn6c   0/1     Completed   0          28h
cronjob-example-29348052-fdx2c   0/1     Completed   0          27s
cronjob-example-29348053-v5wtl   0/1     Completed   0          11s
#查看某个pod
[root@master ~]# kubectl get pod cronjob-example-29346320-jqn6c[这是pod名]
NAME                             READY   STATUS      RESTARTS   AGE
cronjob-example-29346320-jqn6c   0/1     Completed   0          28h
# 查看某个pod,以yaml格式展示结果
[root@master ~]# kubectl get pod cronjob-example-29348052-fdx2c -o yaml

2.2 资源类型

kubernetes中所有的内容都抽象为资源

#查看所有资源
[root@master ~]# kubectl api-resources

在这里插入图片描述

常用资源类型

在这里插入图片描述

kubectl 常见命令操作

在这里插入图片描述

2.3 基本命令示例

kubectl的详细说明地址：https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands

显示集群版本

[root@master ~]# kubectl version
Client Version: v1.30.0
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.30.0

显示集群信息

[root@master ~]# kubectl cluster-info
Kubernetes control plane is running at https://192.168.168.200:6443
CoreDNS is running at https://192.168.168.200:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

2.4 运行和调试命令示例

运行pod

[root@master ~]# kubectl run webserver --image nginx
pod/webserver created
[root@master contral]# kubectl get pods
NAME        READY   STATUS    RESTARTS   AGE
webserver   1/1     Running   0          68s

端口暴漏

[root@master contral]# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   3d5h
------------------------------------------------------------
[root@master contral]# kubectl expose pod webserver --port 80 --target-port  80
service/webserver exposed
[root@master contral]# kubectl get svc
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1      <none>        443/TCP   3d5h
webserver    ClusterIP   10.97.133.54   <none>        80/TCP    5s
#可以访问到nginx服务
[root@master contral]# curl 10.97.133.54
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

查看资源详细信息

[root@master contral]# kubectl describe pods webserver
Name:             webserver
Namespace:        default
Priority:         0
Service Account:  default
Node:             node1/192.168.168.10
Start Time:       Sun, 19 Oct 2025 22:19:30 +0800
Labels:           run=webserver
Annotations:      <none>
Status:           Running
IP:               10.244.1.122
IPs:
  IP:  10.244.1.122
..........................

查看资源日志

[root@master contral]# kubectl logs webserver

在这里插入图片描述

运行交互pod

[root@master contral]# kubectl run -it  testbyx --image busybox
If you don't see a command prompt, try pressing enter.
/ # ls
bin    dev    etc    home   lib    lib64  proc   root   sys    tmp    usr    var
#ctrl+pq退出不停止pod

运行非交互pod

[root@master ~]# kubectl run webserver --image nginx
pod/webserver created
#在已经运行的pod中运行指定命令
[root@master contral]# kubectl exec -it webserver /bin/sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
# ls
bin   dev                  docker-entrypoint.sh  home  lib64  mnt  proc  run   srv  tmp  var
boot  docker-entrypoint.d  etc                   lib   media  opt  root  sbin  sys  usr

复制文件到pod中

[root@master ~]# kubectl cp anaconda-ks.cfg webserver:/
[root@master ~]# kubectl exec -it webserver /bin/sh

在这里插入图片描述

复制pod中的文件到本机

[root@master ~]# kubectl cp webserver:/anaconda-ks.cfg  anaconda-ks.cfg
tar: Removing leading `/' from member names

2.5 高级命令示例

利用命令生成yaml模板文件

[root@master ~]# kubectl create deployment --image nginx webserver --dry-run=client -o yaml > webserver.yml
[root@master ~]# cat webserver.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: webserver
  name: webserver
spec:
  replicas: 1
  selector:
    matchLabels:
      app: webserver
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: webserver
    spec:
      containers:
      - image: nginx
        name: nginx
        resources: {}
status: {}

#执行这个文件
[root@master ~]# kubectl apply -f webserver.yml
deployment.apps/webserver created
#查看控制器
[root@master ~]# kubectl get deployments.apps
NAME        READY   UP-TO-DATE   AVAILABLE   AGE
webserver   1/1     1            1           23s
#查看pod
[root@master ~]# kubectl get pods
NAME                         READY   STATUS    RESTARTS   AGE
webserver-7bc769cd4c-jvz8h   1/1     Running   0          5s
#删除
[root@master ~]# kubectl delete -f webserver.yml
deployment.apps "webserver" deleted
[root@master ~]# kubectl get deployments.apps
No resources found in default namespace.
[root@master ~]# kubectl get pods
No resources found in default namespace.

管理资源标签

[root@master ~]# kubectl run nginx --image nginx
pod/nginx created
[root@master ~]# kubectl get pod --show-labels
NAME    READY   STATUS    RESTARTS   AGE   LABELS
nginx   1/1     Running   0          15s   run=nginx
#添加pod标签
[root@master ~]# kubectl label pod nginx app=lei
pod/nginx labeled
[root@master ~]# kubectl get pod --show-labels
NAME    READY   STATUS    RESTARTS   AGE   LABELS
nginx   1/1     Running   0          51s   app=lei,run=nginx
#修改标签
[root@master ~]# kubectl label pod nginx app=webserver --overwrite
pod/nginx labeled
[root@master ~]# kubectl get pod --show-labels
NAME    READY   STATUS    RESTARTS   AGE    LABELS
nginx   1/1     Running   0          107s   app=webserver,run=nginx
#删除标签
[root@master ~]# kubectl label pods nginx app-
pod/nginx unlabeled
[root@master ~]# kubectl get pod --show-labels
NAME    READY   STATUS    RESTARTS   AGE     LABELS
nginx   1/1     Running   0          2m25s   run=nginx

#删除pod上的标签，控制器会重新启动一个新的pod
[root@master ~]# kubectl apply -f webserver.yml
deployment.apps/webserver created
[root@master ~]# kubectl get pods
NAME                         READY   STATUS    RESTARTS   AGE
webserver-7bc769cd4c-csfv4   1/1     Running   0          5s
[root@master ~]# kubectl get pods --show-labels
NAME                         READY   STATUS    RESTARTS   AGE   LABELS
webserver-7bc769cd4c-csfv4   1/1     Running   0          11s   app=webserver,pod-template-hash=7bc769cd4c
[root@master ~]# kubectl label pod webserver-7bc769cd4c-csfv4 app-
pod/webserver-7bc769cd4c-csfv4 unlabeled
[root@master ~]# kubectl get pods --show-labels
NAME                         READY   STATUS    RESTARTS   AGE   LABELS
webserver-7bc769cd4c-csfv4   1/1     Running   0          29s   pod-template-hash=7bc769cd4c
webserver-7bc769cd4c-hwmrt   1/1     Running   0          3s    app=webserver,pod-template-hash=7bc769cd4c

pod概念

  • Pod是可以创建和管理Kubernetes计算的最小可部署单元
  • 一个Pod代表着集群中运行的一个进程，每个pod都有一个唯一的ip。
  • 一个pod类似一个豌豆荚，包含一个或多个容器（通常是docker）
  • 多个容器间共享IPC、Network和UTC namespace。

在这里插入图片描述

1. 创建自主式pod（生产不推荐）

优点：

灵活性高：

  • 可以精确控制 Pod 的各种配置参数，包括容器的镜像、资源限制、环境变量、命令和参数等，满足特定的应用需求。

学习和调试方便：

  • 对于学习 Kubernetes 的原理和机制非常有帮助，通过手动创建 Pod 可以深入了解 Pod 的结构和配置方式。在调试问题时，可以更直接地观察和调整 Pod 的设置。

适用于特殊场景：

  • 在一些特殊情况下，如进行一次性任务、快速验证概念或在资源受限的环境中进行特定配置时，手动创建 Pod 可能是一种有效的方式。

缺点：

管理复杂：

  • 如果需要管理大量的 Pod，手动创建和维护会变得非常繁琐和耗时。难以实现自动化的扩缩容、故障恢复等操作。

缺乏高级功能：

  • 无法自动享受 Kubernetes 提供的高级功能，如自动部署、滚动更新、服务发现等。这可能导致应用的部署和管理效率低下。

可维护性差：

  • 手动创建的 Pod 在更新应用版本或修改配置时需要手动干预，容易出现错误，并且难以保证一致性。相比之下，通过声明式配置或使用 Kubernetes 的部署工具可以更方便地进行应用的维护和更新。
#建立一个名为jinbaolei的pod
[root@master ~]# kubectl run jinbaolei --image nginx
pod/jinbaolei created
[root@master ~]# kubectl get pods
NAME        READY   STATUS    RESTARTS   AGE
jinbaolei   1/1     Running   0          4s
#查看较为详细的pod信息
[root@master ~]# kubectl get pods -o wide
NAME        READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
jinbaolei   1/1     Running   0          28s   10.244.1.124   node1   <none>           <none>

2. 利用控制器管理pod（推荐）

高可用性和可靠性：

  • 自动故障恢复：如果一个 Pod 失败或被删除，控制器会自动创建新的 Pod 来维持期望的副本数量。确保应用始终处于可用状态，减少因单个 Pod 故障导致的服务中断。
  • 健康检查和自愈：可以配置控制器对 Pod 进行健康检查（如存活探针和就绪探针）。如果 Pod 不健康，控制器会采取适当的行动，如重启 Pod 或删除并重新创建它，以保证应用的正常运行。

可扩展性：

  • 轻松扩缩容：可以通过简单的命令或配置更改来增加或减少 Pod 的数量，以满足不同的工作负载需求。例如，在高流量期间可以快速扩展以处理更多请求，在低流量期间可以缩容以节省资源。
  • 水平自动扩缩容（HPA）：可以基于自定义指标（如 CPU 利用率、内存使用情况或应用特定的指标）自动调整 Pod 的数量，实现动态的资源分配和成本优化。

版本管理和更新：

  • 滚动更新：对于 Deployment 等控制器，可以执行滚动更新来逐步替换旧版本的 Pod 为新版本，确保应用在更新过程中始终保持可用。可以控制更新的速率和策略，以减少对用户的影响。
  • 回滚：如果更新出现问题，可以轻松回滚到上一个稳定版本，保证应用的稳定性和可靠性。

声明式配置：

  • 简洁的配置方式：使用 YAML 或 JSON 格式的声明式配置文件来定义应用的部署需求。这种方式使得配置易于理解、维护和版本控制，同时也方便团队协作。
  • 期望状态管理：只需要定义应用的期望状态（如副本数量、容器镜像等），控制器会自动调整实际状态与期望状态保持一致。无需手动管理每个 Pod 的创建和删除，提高了管理效率。

服务发现和负载均衡：

  • 自动注册和发现：Kubernetes 中的服务（Service）可以自动发现由控制器管理的 Pod，并将流量路由到它们。这使得应用的服务发现和负载均衡变得简单和可靠，无需手动配置负载均衡器。
  • 流量分发：可以根据不同的策略（如轮询、随机等）将请求分发到不同的 Pod，提高应用的性能和可用性。

多环境一致性：

  • 一致的部署方式：在不同的环境（如开发、测试、生产）中，可以使用相同的控制器和配置来部署应用，确保应用在不同环境中的行为一致。这有助于减少部署差异和错误，提高开发和运维效率。

示例

建立控制器并且自动运行pod

[root@master ~]# kubectl create deployment jinbaolei --image nginx
deployment.apps/jinbaolei created
[root@master ~]# kubectl get pods
NAME                         READY   STATUS    RESTARTS   AGE
jinbaolei-65dd549f55-lv4g2   1/1     Running   0          6s
#给控制器jinbaolei扩容
[root@master ~]# kubectl scale deployment jinbaolei --replicas 3
deployment.apps/jinbaolei scaled
[root@master ~]# kubectl get pods
NAME                         READY   STATUS    RESTARTS   AGE
jinbaolei-65dd549f55-2v6x5   1/1     Running   0          3s
jinbaolei-65dd549f55-lv4g2   1/1     Running   0          26s
jinbaolei-65dd549f55-ncvt5   1/1     Running   0          3s
#给控制器jinbaolei缩容
[root@master ~]# kubectl scale deployment jinbaolei --replicas 2
deployment.apps/jinbaolei scaled
[root@master ~]# kubectl get pods
NAME                         READY   STATUS    RESTARTS   AGE
jinbaolei-65dd549f55-2v6x5   1/1     Running   0          54s
jinbaolei-65dd549f55-lv4g2   1/1     Running   0          77s
[root@master ~]#

3. 应用版本的更新

利用控制器简历pod

[root@master ~]# kubectl create deployment jinbaolei --image myapp:v1 --replicas  2
deployment.apps/jinbaolei created
[root@master ~]# kubectl get pods
NAME                         READY   STATUS    RESTARTS   AGE
jinbaolei-8665699bc6-hft4w   1/1     Running   0          1s
jinbaolei-8665699bc6-kcqw7   1/1     Running   0          1s
#暴露端口
[root@master ~]# kubectl expose deployment jinbaolei --port 80 --target-port 80
service/jinbaolei exposed
[root@master ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
jinbaolei    ClusterIP   10.103.38.197   <none>        80/TCP    26s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   3d6h
#访问服务
[root@master ~]# curl 10.103.38.197
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

#查看历史版本
[root@master ~]# kubectl rollout history deployment jinbaolei
deployment.apps/jinbaolei
REVISION  CHANGE-CAUSE
1         <none>

更新控制器镜像版本

[root@master ~]# kubectl set image deployments/jinbaolei myapp=myapp:v2
deployment.apps/jinbaolei image updated
[root@master ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
jinbaolei    ClusterIP   10.103.38.197   <none>        80/TCP    4m2s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   3d6h
webserver    ClusterIP   10.97.133.54    <none>        80/TCP    37m
#再次访问版本变成v2
[root@master ~]# curl 10.103.38.197
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>
#再次产看历史版本
[root@master ~]# kubectl rollout history deployment jinbaolei
deployment.apps/jinbaolei
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

版本回滚

[root@master ~]# kubectl rollout undo deployment jinbaolei --to-revision 1
deployment.apps/jinbaolei rolled back
[root@master ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
jinbaolei    ClusterIP   10.103.38.197   <none>        80/TCP    5m19s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   3d6h
webserver    ClusterIP   10.97.133.54    <none>        80/TCP    38m
[root@master ~]# curl 10.103.38.197
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

4. 利用yaml文件部署应用

4.1 用yaml文件部署应用有以下优点

声明式配置：

  • 清晰表达期望状态：以声明式的方式描述应用的部署需求，包括副本数量、容器配置、网络设置等。这使得配置易于理解和维护，并且可以方便地查看应用的预期状态。
  • 可重复性和版本控制：配置文件可以被版本控制，确保在不同环境中的部署一致性。可以轻松回滚到以前的版本或在不同环境中重复使用相同的配置。
  • 团队协作：便于团队成员之间共享和协作，大家可以对配置文件进行审查和修改，提高部署的可靠性和稳定性。

灵活性和可扩展性：

  • 丰富的配置选项：可以通过 YAML 文件详细地配置各种 Kubernetes 资源，如 Deployment、Service、ConfigMap、Secret 等。可以根据应用的特定需求进行高度定制化。
  • 组合和扩展：可以将多个资源的配置组合在一个或多个 YAML 文件中，实现复杂的应用部署架构。同时，可以轻松地添加新的资源或修改现有资源以满足不断变化的需求。

与工具集成：

  • 与 CI/CD 流程集成：可以将 YAML 配置文件与持续集成和持续部署（CI/CD）工具集成，实现自动化的应用部署。例如，可以在代码提交后自动触发部署流程，使用配置文件来部署应用到不同的环境。
  • 命令行工具支持：Kubernetes 的命令行工具 kubectl 对 YAML 配置文件有很好的支持，可以方便地应用、更新和删除配置。同时，还可以使用其他工具来验证和分析 YAML 配置文件，确保其正确性和安全性。

4.2 资源清单参数

参数名称类型参数说明
versionString这里是指的是K8S API的版本，目前基本上是v1，可以用kubectl api-versions命令查询
kindString这里指的是yaml文件定义的资源类型和角色，比如:Pod
metadataObject元数据对象，固定值就写metadata
metadata.nameString元数据对象的名字，这里由我们编写，比如命名Pod的名字
metadata.namespaceString元数据对象的命名空间，由我们自身定义
SpecObject详细定义对象，固定值就写Spec
spec.containers[]list这里是Spec对象的容器列表定义，是个列表
spec.containers[].nameString这里定义容器的名字
spec.containers[].imagestring这里定义要用到的镜像名称
spec.containers[].imagePullPolicyString定义镜像拉取策略，有三个值可选： (1) Always: 每次都尝试重新拉取镜像 (2) IfNotPresent:如果本地有镜像就使用本地镜像 (3) )Never:表示仅使用本地镜像
spec.containers[].command[]list指定容器运行时启动的命令，若未指定则运行容器打包时指定的命令
spec.containers[].args[]list指定容器运行参数，可以指定多个
spec.containers[].workingDirString指定容器工作目录
spec.containers[].volumeMounts[]list指定容器内部的存储卷配置
spec.containers[].volumeMounts[].nameString指定可以被容器挂载的存储卷的名称
spec.containers[].volumeMounts[].mountPathString指定可以被容器挂载的存储卷的路径
spec.containers[].volumeMounts[].readOnlyString设置存储卷路径的读写模式，ture或false，默认为读写模式
spec.containers[].ports[]list指定容器需要用到的端口列表
spec.containers[].ports[].nameString指定端口名称
spec.containers[].ports[].containerPortString指定容器需要监听的端口号
spec.containers[] ports[].hostPortString指定容器所在主机需要监听的端口号，默认跟上面containerPort相同，注意设置了hostPort同一台主机无法启动该容器的相同副本(因为主机的端口号不能相同，这样会冲突)
spec.containers[].ports[].protocolString指定端口协议，支持TCP和UDP，默认值为 TCP
spec.containers[].env[]list指定容器运行前需设置的环境变量列表
spec.containers[].env[].nameString指定环境变量名称
spec.containers[].env[].valueString指定环境变量值
spec.containers[].resourcesObject指定资源限制和资源请求的值(这里开始就是设置容器的资源上限)
spec.containers[].resources.limitsObject指定设置容器运行时资源的运行上限
spec.containers[].resources.limits.cpuString指定CPU的限制，单位为核心数，1=1000m
spec.containers[].resources.limits.memoryString指定MEM内存的限制，单位为MIB、GiB
spec.containers[].resources.requestsObject指定容器启动和调度时的限制设置
spec.containers[].resources.requests.cpuStringCPU请求，单位为core数，容器启动时初始化可用数量
spec.containers[].resources.requests.memoryString内存请求，单位为MIB、GIB，容器启动的初始化可用数量
spec.restartPolicystring定义Pod的重启策略，默认值为Always. (1)Always: Pod-旦终止运行，无论容器是如何 终止的，kubelet服务都将重启它 (2)OnFailure: 只有Pod以非零退出码终止时，kubelet才会重启该容器。如果容器正常结束(退出码为0)，则kubelet将不会重启它 (3) Never: Pod终止后，kubelet将退出码报告给Master，不会重启该
spec.nodeSelectorObject定义Node的Label过滤标签，以key:value格式指定
spec.imagePullSecretsObject定义pull镜像时使用secret名称，以name:secretkey格式指定
spec.hostNetworkBoolean定义是否使用主机网络模式，默认值为false。设置true表示使用宿主机网络，不使用docker网桥，同时设置了true将无法在同一台宿主机 上启动第二个副本

4.3 如何获得资源帮助

[root@master ~]# kubectl explain pod.spec.containers

4.4 编写示例

示例1：运行简单的单个容器pod

用命令获取yaml模板

[root@master ~]# kubectl run jinaboei --image nginx --dry-run=client -o yaml > pod.yml
[root@master ~]# cat p
cat: p: 没有那个文件或目录
[root@master ~]# cat pod.yml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: jinaboei  #pod标签
  name: jinaboei   #pod名称
spec:
  containers:
  - image: nginx   #pod镜像
    name: jinaboei #容器名称
示例2：运行多个容器pod

注意：

注意如果多个容器运行在一个pod中，资源共享的同时在使用相同资源时也会干扰，比如端口。比如两个nginx容器运行时可能会发生抢占端口。

端口干扰示例：

[root@master ~]# kubectl apply -f pod.yml
pod/jinaboei created
[root@master ~]# kubectl get pods
NAME       READY   STATUS   RESTARTS     AGE
jinaboei   1/2     Error    1 (7s ago)   10s
#查看日志
[root@master ~]# kubectl logs jinaboei myapp2
2025/10/20 05:43:29 [emerg] 1#1: bind() to 0.0.0.0:80 failed (98: Address in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address in use)
2025/10/20 05:43:29 [emerg] 1#1: bind() to 0.0.0.0:80 failed (98: Address in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address in use)
2025/10/20 05:43:29 [emerg] 1#1: bind() to 0.0.0.0:80 failed (98: Address in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address in use)
2025/10/20 05:43:29 [emerg] 1#1: bind() to 0.0.0.0:80 failed (98: Address in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address in use)
2025/10/20 05:43:29 [emerg] 1#1: bind() to 0.0.0.0:80 failed (98: Address in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address in use)
2025/10/20 05:43:29 [emerg] 1#1: still could not bind()
nginx: [emerg] still could not bind()
示例3：理解pod间的网络整合

同在一个pod中的容器公用一个网络

[root@master ~]# vim pod.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: jinaboei
  name: jinaboei
spec:
  containers:
    - image: myapp:v1
      name: myapp1

    - image: busybox
      name: busybox
      command: ["/bin/sh", "-c", "sleep 100000"]
~

[root@master ~]# kubectl apply -f pod.yml
pod/jinaboei created
[root@master ~]# kubectl get pods
NAME       READY   STATUS    RESTARTS   AGE
jinaboei   2/2     Running   0          5s

#可以看到两个容器的网络IP一样
[root@master ~]# kubectl exec jinaboei -it -c myapp1 /bin/sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP
    link/ether 06:ae:01:0a:38:c1 brd ff:ff:ff:ff:ff:ff
    inet 10.244.1.131/24 brd 10.244.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::4ae:1ff:fe0a:38c1/64 scope link
       valid_lft forever preferred_lft forever
/ # exit
[root@master ~]# kubectl exec jinaboei -it -c busybox /bin/sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
/ #
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue
    link/ether 06:ae:01:0a:38:c1 brd ff:ff:ff:ff:ff:ff
    inet 10.244.1.131/24 brd 10.244.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::4ae:1ff:fe0a:38c1/64 scope link
       valid_lft forever preferred_lft forever
/ #
示例4：端口映射
[root@master ~]# cat pod.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: jinaboei
  name: jinaboei
spec:
  containers:
    - image: myapp:v1
      name: myapp1
      ports:
      - name: http
        containerPort: 80
        hostPort: 80
        protocol: TCP
[root@master ~]# kubectl get pods
NAME       READY   STATUS    RESTARTS   AGE
jinaboei   1/1     Running   0          6s
[root@master ~]# kubectl get pods -o wide
NAME       READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
jinaboei   1/1     Running   0          14s   10.244.2.119   node2   <none>           <none>
[root@master ~]# curl node2
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
示例5：如何设定环境变量
#配置mysql容器的时候，不写环境变量是无法启动容器的会报错
[root@master ~]# cat pod.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: jinaboei
  name: jinaboei
spec:
  containers:
    - image: mysql:8.0
      name: mysql
      env:
        - name: MYSQL_ROOT_PASSWORD
          value: "123"
[root@master ~]# kubectl apply -f pod.yml
pod/jinaboei created
[root@master ~]# kubectl get pods
NAME       READY   STATUS    RESTARTS   AGE
jinaboei   1/1     Running   0          5s
示例6：资源限制

**注意：**资源限制会影响pod的Qos Class资源优先级，资源优先级分为Guaranteed > Burstable > BestEffort

QoS（Quality of Service）即服务质量

资源设定优先级类型
资源限定未设定BestEffort
资源限定设定且最大和最小不一致Burstable
资源限定设定且最大和最小一致Guaranteed

未设定的情况：

在这里插入图片描述

Guaranteed

[root@master ~]# cat pod.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: jinaboei
  name: jinaboei
spec:
  containers:
    - image: mysql:8.0
      name: mysql
      resources:
        limits:                 #pod使用资源的最高限制
          cpu: 500m
          memory: 100M
        requests:               #pod期望使用资源量，不能大于limits
          cpu: 500m
          memory: 100M
[root@master ~]# kubectl apply -f pod.yml
pod/jinaboei created
[root@master ~]# kubectl describe pods jinaboei
Volumes:
  kube-api-access-5n6lc:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Guaranteed
Node-Selectors:              <none>

Burstable

[root@master ~]# cat pod.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: jinaboei
  name: jinaboei
spec:
  containers:
    - image: nginx
      name: nginx
      resources:
        limits:
          cpu: 500m
          memory: 100M
        requests:
          cpu: 400m
          memory: 90M
[root@master ~]# kubectl apply -f pod.yml
pod/jinaboei created
[root@master ~]# kubectl get pods
NAME       READY   STATUS    RESTARTS   AGE
jinaboei   1/1     Running   0          4s
[root@master ~]# kubectl describe pods/jinaboei
Volumes:
  kube-api-access-hxvbz:
    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>
示例7：选择运行节点
[root@master ~]# cat pod.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: jinaboei
  name: jinaboei
spec:
  nodeSelector:
    kubernetes.io/hostname: node1  #指定运行节点为node1
  containers:
    - image: nginx
      name: nginx
[root@master ~]# kubectl apply -f pod.yml
pod/jinaboei created
[root@master ~]# kubectl get pods
NAME       READY   STATUS    RESTARTS   AGE
jinaboei   1/1     Running   0          17s
--------------------------------------------------------------
#node1节点
[root@master ~]# kubectl get pods -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP             NODE    NOMINATED NODE   READINESS GATES
jinaboei   1/1     Running   0          2m59s   10.244.1.139   node1   <none>           <none>
示例9：共享宿主机网络
[root@master ~]# cat pod.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: jinaboei
  name: jinaboei
spec:
  hostNetwork: true
  containers:
    - image: busybox
      name: busybox
      command: ["/bin/sh", "-c", "sleep 100000"]
[root@master ~]# kubectl apply -f pod.yml
pod/jinaboei created
[root@master ~]# kubectl get pods
NAME       READY   STATUS    RESTARTS   AGE
jinaboei   1/1     Running   0          4s
#进入到容器里查看IP，和宿主机的IP是一样的
[root@master ~]# kubectl exec jinaboei -it -c busybox /bin/sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
/ #
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq qlen 1000
    link/ether 00:0c:29:b7:3e:36 brd ff:ff:ff:ff:ff:ff
    inet 192.168.168.10/24 brd 192.168.168.255 scope global noprefixroute ens160
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:feb7:3e36/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

Pod的生命周期

1. INIT容器

官方文档：https://kubernetes.io/zh/docs/concepts/workloads/pods/

在这里插入图片描述

  • Pod 可以包含多个容器，应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。

  • Init 容器与普通的容器非常像，除了如下两点：

    • 它们总是运行到完成

    • init 容器不支持 Readiness，因为它们必须在 Pod 就绪之前运行完成，每个 Init 容器必须运行成功，下一个才能够运行。

  • 如果Pod的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。但是，如果 Pod 对应的 restartPolicy 值为 Never，它不会重新启动。

1.1 INIT容器的功能

  • Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。
  • Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
  • 应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
  • Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 Secrets 的权限，而应用容器不能够访问。
  • 由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动。

1.2 INIT容器示例

[root@master ~]# cat pod.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: jinaboei
  name: jinaboei
spec:
  hostNetwork: true
  containers:
    - image: myapp:v1
      name: myapp
  initContainers:
    - name: init-myservice
      image: busybox
      command: ["sh", "-c", "until test -e /testfile;do echo wating for myservice; sleep 2; done"]
[root@master ~]# kubectl apply -f pod.yml
pod/jinaboei created
#发现Init没有正常就绪，这是因为myapp根下没有testfile文件
[root@master ~]# kubectl get pods
NAME       READY   STATUS     RESTARTS   AGE
jinaboei   0/1     Init:0/1   0          5s
[root@master ~]# kubectl logs pods/jinaboei
init-myservice  myapp
[root@master ~]# kubectl logs pods/jinaboei init-myservice
wating for myservice
wating for myservice
wating for myservice
wating for myservice
wating for myservice
wating for myservice
wating for myservice
wating for myservice
wating for myservice
wating for myservice
wating for myservice
wating for myservice
wating for myservice
wating for myservice
wating for myservice
wating for myservice

#进如容器里创建 testfile 文件，后容器就可以正常启动了
[root@master ~]# kubectl exec -it  pods/jinaboei -c init-myservice  /bin/sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
/ #
/ # touch /testfile
/ # command terminated with exit code 137
[root@master ~]# kubectl get pods
NAME       READY   STATUS    RESTARTS   AGE
jinaboei   1/1     Running   0          2m40s

2. 探针

探针是由 kubelet 对容器执行的定期诊断:

  • ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
  • TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
  • HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。

每次探测都将获得以下三种结果之一：

  • 成功：容器通过了诊断。
  • 失败：容器未通过诊断。
  • 未知：诊断失败，因此不会采取任何行动。

Kubelet 可以选择是否执行在容器上运行的三种探针执行和做出反应：

  • livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为 Success。
  • readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。
  • startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探测(startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success。

ReadinessProbe 与 LivenessProbe 的区别

  • ReadinessProbe 当检测失败后，将 Pod 的 IP:Port 从对应的 EndPoint 列表中删除。
  • LivenessProbe 当检测失败后，将杀死容器并根据 Pod 的重启策略来决定作出对应的措施

StartupProbe 与 ReadinessProbe、LivenessProbe 的区别

  • 如果三个探针同时存在，先执行 StartupProbe 探针，其他两个探针将会被暂时禁用，直到 pod 满足 StartupProbe 探针配置的条件，其他 2 个探针启动，如果不满足按照规则重启容器。
  • 另外两种探针在容器启动后，会按照配置，直到容器消亡才停止探测，而 StartupProbe 探针只是在容器启动后按照配置满足一次后，不在进行后续的探测。

2.1 探针实例

2.1.1 存活探针示例
[root@master ~]# cat pod.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: liveness
  name: liveness
spec:
  hostNetwork: true
  containers:
    - image: myapp:v1
      name: myapp
      livenessProbe:
        tcpSocket:     			#检测8080端口是是否存在
          port: 8080   
        initialDelaySeconds: 3  #容器启动后要等待多少秒后就探针开始工作，默认是 0
        periodSeconds: 1     #执行探测的时间间隔，默认为 10s
        timeoutSeconds: 1   #探针执行检测请求后，等待响应的超时时间，默认为 1s
[root@master ~]# kubectl apply -f pod.yml
pod/liveness created
#因为myapp容器里没有开启8080端口，所以存活探针一直重复执行
[root@master ~]# kubectl get pods
NAME       READY   STATUS             RESTARTS     AGE
liveness   0/1     CrashLoopBackOff   2 (9s ago)   24s
2.1.2 就绪探针示例
[root@master ~]# cat pod.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: readiness
  name: readiness
spec:
  hostNetwork: true
  containers:
    - image: myapp:v1
      name: myapp
      readinessProbe:
        httpGet:
          path: /test.html
          port: 80
        initialDelaySeconds: 3
        periodSeconds: 3
        timeoutSeconds: 1
[root@master ~]# kubectl apply -f pod.yml
pod/readiness created
[root@master ~]# kubectl get pods
NAME        READY   STATUS    RESTARTS   AGE
readiness   0/1     Running   0          4s
#进入myapp容器创建test.html文件
[root@master ~]# kubectl exec -it readiness -c myapp /bin/sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
/ # echo haha > /usr/share/nginx/html/test.html
/ # exit
[root@master ~]# kubectl get pods
NAME        READY   STATUS    RESTARTS   AGE
readiness   1/1     Running   0          4m39s
Kubernetes 简介与部署全攻略
刘大帅ps的博客
09-05 2296
Kubernetes，通常简称为 K8s，是一个开源的容器编排平台，用于自动化部署、扩展和管理容器化应用程序。 它最初由 Google 设计并开发，基于 Google 多年来在大规模容器管理方面的经验。Kubernetes 的目标是提供一个可靠、可扩展且高效的平台，让开发者能够轻松地在不同的环境中运行和管理容器化的应用。
HoRain云--Kubernetes Pod部署全攻略
sinat_57153473的博客
10-22 1537
摘要：本文介绍了Kubernetes（K8s）的核心概念与Pod部署流程。K8s作为容器编排平台，提供自动化运维、服务治理和资源管理功能。部署Pod分为三个步骤：编写YAML配置文件（定义容器、资源等）、使用kubectl提交配置、验证Pod状态（Running为成功）。流程涉及APIServer、etcd、Scheduler和kubelet等组件协同工作。建议优先使用Deployment管理Pod以提高容错性，并善用标签筛选资源。文章附有配置示例和创建流程图，适合初学者快速上手K8s基础操作。
从小白到大神：Kubernetes集群实战全攻略
大雨淅淅的博客
10-26 1762
本文系统介绍了Kubernetes集群的部署与管理全过程。从Kubernetes的基本概念入手，详细讲解了环境准备、集群部署、管理与运维等核心内容，包括服务器规划、网络存储配置、kubeadm初始化、节点加入、网络插件安装等关键步骤。在管理与运维部分，重点阐述了Pod、Service、Deployment的管理方法以及监控排错技巧。同时提供了集群扩缩容、资源调度优化和高可用配置等进阶内容，并以Nginx和SpringCloud微服务为例演示了实战部署过程。全文循序渐进地展示了Kubernetes从入门到实战
AI模型部署全攻略：Docker与Kubernetes实战指南！
2401_85343303的博客
09-25 858
本文详细介绍了AI模型部署的容器化与云原生技术。首先阐述了容器化(Docker)的优势，包括环境一致性、依赖隔离和版本管理；然后介绍了Kubernetes的核心组件及其在AI部署中的应用；最后讲解了NVIDIA Triton推理平台的架构和工作流程。文章强调了容器化与云原生技术如何解决AI模型部署中的环境兼容、弹性伸缩、资源调度等工程挑战，为AI从实验室到生产环境的落地提供了实用指导。
K8s Custom Resource Definition（自定义资源定义）K8s CRDS介绍
Dontla的博客
06-22 242
CRD = Kubernetes 的“插件式 API 扩展机制”避免引入额外 CRD，坚持使用标准 Kubernetes Ingress + 注解方式管理 Kong 配置，以保持简洁性和兼容性。
开发K8s准入控制器前的准备工作：集群检查与项目搭建指南
java_cj的专栏
06-20 390
开发Kubernetes准入控制器的准备工作 本文详细介绍了开发Kubernetes准入控制器前的环境检查和项目初始化步骤： 集群环境检查： 验证集群是否支持准入注册API（admissionregistration.k8s.io/v1） 确认kube-apiserver启用了MutatingAdmissionWebhook和ValidatingAdmissionWebhook插件 测试Webhook连通性 项目初始化： 创建Go项目结构，添加必要的Kubernetes API依赖 设计Sidecar注入配
《容器运行时与 K8s 集群搭建：nerdctl + crictl + kubeadm 》
2301_78529310的博客
06-23 256
crictl命令是遵循 CRI 接口规范的一个命令行工具，通常用它来检查和管理kubelet节点上的容器运行时和镜像。在kubernetes集群环境中，当我们执行kubectl命令式，kubelet代理会自动调用crictl命令管理镜像和容器。手动执行crictl命令时，一般用于查看镜像和容器。传统部署时代：企业在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。
K8s 阿里云 ECS 工作节点添加指南
探索云原生与智能化驱动下的安全运维新范式。关注DevSecOps、可观测性、AIOps等前沿领域，与您共赴技术前沿。
06-22 196
按需追加。置空则保持默认。
LAC容器化授权困境（下篇）：K8s环境下的授权锚定实战
程序边界
06-21 4818
但说实话，这个方案的问题比它解决的问题多。最要命的是，如果节点挂了，那个预留IP就跟着死了——除非你的节点池足够大，调度器能在另一个节点上重新拉起Pod并分配到同一个IP，但这个"除非"在生产环境里根本不能保证。这些幽灵记录虽然不直接占license配额（offline的授权理论上可以被重新分配），但它们会干扰你的判断——你在WEB界面上看，100个客户端里只有30个在线，你以为授权池有70个富余，但其实那70个offline记录对应的Pod可能随时重新上线（比如之前只是网络抖动，Pod进程其实还在）。
K8s 集群 NFS 存储部署流程
专注Linux运维与云原生技术分享。这里是我的技术成长基地，记录从Linux基础命令到Shell脚本，再到Docker、K8s实战的点滴积累。坚持输出干货笔记，希望能帮你避坑排雷，共同在云原生时代进阶！
06-20 244
sc.yamlmetadata:annotations: #标记为集群默认存储类。
Kubernetes 基础入门实战
cpyaxjq的博客
06-22 405
本文是一篇Kubernetes实战教程，详细记录了在华为云FlexusX ECS服务器上搭建K8s v1.30.14集群的全过程。文章首先介绍了4台服务器的规划配置（1个Master+3个Worker），然后逐步展示了环境初始化、containerd镜像加速配置、kubeadm集群初始化、Flannel网络插件安装等关键步骤，并特别标注了国内环境可能遇到的镜像拉取问题及解决方案。教程采用"理论+实践+踩坑记录"的形式，所有命令均来自真实环境验证，适合初学者快速掌握K8s集群搭建的核心要点。
Kubernetes RBAC 实战指南
最新发布
探索云原生与智能化驱动下的安全运维新范式。关注DevSecOps、可观测性、AIOps等前沿领域，与您共赴技术前沿。
06-24 160
kind: Rolemetadata:rules:# 允许读取 Pod- apiGroups: [""] # 核心 API 组resources: ["pods"] # 资源类型verbs: ["get", "list", "watch"] # 操作# 允许读取 Pod 日志。
1.1 大模型面试经验 k8s容器，大模型输出检测 RAG 与 Tool-calling
你是人间四月天
06-22 266
提及大模型推理特性：如“我会用 vLLM 或 TensorRT-LLM 做推理加速，因为 LLM 是 memory-bound 型任务，Batch Size 调优是关键”。提及 MCP 与 Autogen 的区别：如果面试官问及多智能体，可以补充：“Autogen 更偏向对话式多智能体（Conversational），而 LangGraph 更适合状态机驱动的确定性工作流，我倾向于结合两者，核心流程用 Graph，边缘探索用 Autogen”。针对你之前提供的 JD 和面试题库，我提炼出了。
[特殊字符] 第二篇：班级留言板 K8s 部署实践（下）—— 服务暴露与滚动更新
A516988的博客
06-22 215
本文介绍了在Kubernetes集群中通过Service(NodePort)对外暴露应用的具体实践，包括端口规划、配置验证和访问测试。重点演示了滚动更新与回滚机制的操作流程，通过修改镜像版本和Deployment配置实现零停机更新，并支持快速回退到历史版本。文章还提供了常见问题排查方法，比较了不同Service类型的适用场景，总结了Docker和Kubernetes在环境一致性和容器编排方面的核心价值，体现了云原生架构中不可变基础设施与配置分离的设计理念。
手撕 K8s MutatingWebhook：sidecar 自动注入的 mutatePod 函数
java_cj的专栏
06-21 426
文章摘要 本文详细剖析了Kubernetes MutatingAdmissionWebhook的核心实现逻辑，聚焦serveMutate和mutatePod两个关键函数。作者通过一个线上事故案例（因annotation键名变更导致sidecar注入失败）引出问题，深入解析了webhook请求处理流程：包括HTTP基础校验、准入控制请求反序列化、注入条件判断（重点指出mutationRequired函数中默认返回false的陷阱）以及响应生成机制。特别强调了版本兼容性（v1beta1在K8s 1.22+失效）
K8s sidecar 注入器实战部署：从 CA 签名、镜像构建到 MutatingWebhook 上线全流程
java_cj的专栏
06-21 289
代码写完了，单测过了，本地起 webhook server 也没问题。本以为部署就是体力活——把代码打成镜像 → 推到节点 →一把梭 → 收工下班。理想很美好。第一次部署，证书签错了，APIServer 调 webhook 直接第二次重新签，CABundle 填的是 base64 解码后的内容，APIServer 还是不认第三次终于过了认证，但 Pod 创建出来没有 sidecar——日志里没有任何报错第四次发现 namespaceSelector 的 label 写反了第五次……
K8s Pod DNS 解析间歇性失败：conntrack 打满引发的线上事故
JackDan9
06-24 141
conntrack 是隐藏杀手— K8s 每个 Service 访问都走 conntrack，高并发必成瓶颈。不只是 DNS，所有跨 Pod 通信都受影响NodeLocal DNSCache = 标配— 生产集群不部署就是在埋雷。官方文档明确推荐，但很多人忽略JVM DNS 默认永久缓存很危险etworkaddress.cache.ttl=-1 在 K8s 动态 IP 环境下会导致 Pod 漂移后永远解析不到新地址。所有 Java 服务必须显式设置 TTL监控前置。
kubernetes（K8s）学习笔记（第二期）：Kubernetes 集群部署实战（kubeadm）
AOwhisky的博客
06-23 339
阶段关键操作关键命令环境准备配置仓库、安装软件、关闭 swapapt updateswapoff -a内核配置加载模块、配置 sysctlmodprobesysctl -p容器运行时安装 containerd、配置加速安装 K8s安装 kubeadm/kubelet/kubectl克隆节点克隆 VM、配置 IP/主机名集群初始化网络插件部署 Calico加入节点worker 加入集群。
【Kubernetes】K8s集群的node节点因为证书过期导致的notReady问题处理
cnskylee的博客
06-17 96
Kubernetes集群节点因证书过期更新后出现NotReady状态，通过重新生成join命令并执行节点重连时遇到两类错误：1）配置文件/端口冲突问题，通过重命名旧证书文件、停止kubelet服务解决；2）节点权限问题，使用kubeadm reset清理节点配置后成功重连。最终所有节点状态恢复Ready，集群恢复正常。关键步骤包括处理预检错误、重置节点配置和重新加入集群。
kubernetes（K8s）学习笔记（第一期）：容器管理基础与 Kubernetes 架构初探
AOwhisky的博客
06-23 196
nerdctl 和 Docker 一样，默认使用OverlayFS作为存储驱动。它利用 Linux 内核的 OverlayFS 特性，实现镜像分层存储：textContainer Layer (读写层) ←── 容器启动时创建↑Image Layer 3 (只读) ←── 最上层镜像Image Layer 2 (只读) ←── 中间层Image Layer 1 (只读) ←── 基础镜像层优点镜像分层存储，相同层可在不同容器间共享，节省磁盘空间容器启动时只需创建薄薄一层读写层，启动飞快。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值