Kubernetes YAML 入门指南 – wiki基地


Kubernetes YAML 入门指南:揭秘云原生世界的“魔法契约”

在云原生时代,Kubernetes (K8s) 已经成为容器编排的事实标准。它强大、灵活,能够自动化部署、扩展和管理容器化应用。然而,对于许多初学者来说,与 Kubernetes 交互的第一道难关往往是那些看似复杂、由缩进和键值对组成的文本文件——Kubernetes YAML。

YAML 文件就像是与 Kubernetes 集群沟通的“魔法契约”,你通过它们来描述你期望系统达到的状态:你想要运行多少个应用副本?它们需要哪些资源?如何让外部用户访问它们?等等。掌握 YAML,就如同获得了与 Kubernetes 对话的能力。

本文将带你深入了解 Kubernetes YAML 的世界,从基础语法到核心资源对象的配置,手把手教你如何编写、应用和理解这些重要的配置文件。

第一部分:什么是 YAML?为什么 Kubernetes 使用它?

1.1 YAML 是什么?

YAML 是 “YAML Ain’t Markup Language”(YAML 不是标记语言)的递归缩写,最初的意思是 “Yet Another Markup Language”(另一种标记语言)。它是一种人类可读的数据序列化格式,常用于配置文件、数据交换和数据持久化。

YAML 的设计哲学是简洁、易读。它使用缩进来表示数据的层级结构,这与 Python 等语言的风格类似。相比于 XML 的繁琐标签或 JSON 的大括号和引号,YAML 通常更加直观。

YAML 基础语法特点:

  • 键值对 (Key-Value Pairs): 使用冒号 : 分隔键和值。冒号后面通常有一个空格。
    yaml
    name: my-application
    version: 1.0
  • 列表 (Lists/Sequences): 使用短划线 - 开头表示列表项。
    “`yaml
    fruits:

    • apple
    • banana
    • orange
      “`
  • 嵌套 (Nesting/Mapping): 使用缩进来表示层级关系。每个层级通常增加两个空格作为缩进(尽管标准允许任意数量的空格,但通常建议一致使用 2 或 4 个空格)。
    yaml
    person:
    name: Alice
    age: 30
    address:
    city: New York
    zip: "10001" # 值如果是数字或其他类型,也可以用引号括起来,特别是字符串
  • 字符串 (Strings): 大多数情况下不需要引号,除非字符串包含特殊字符(如冒号、井号 #、短划线 - 等)或需要保留前导/后导空格。
  • 注释 (Comments): 使用 # 符号表示注释,从 # 到行尾的内容都会被忽略。
    yaml
    # 这是一个注释
    key: value # 行末注释
  • 多文档: 使用 --- 分隔符可以在同一个 YAML 文件中包含多个独立的 YAML 文档(在 Kubernetes 中非常常见,一个文件可以定义多个资源对象)。

1.2 为什么 Kubernetes 选择 YAML?

Kubernetes 选择 YAML 作为主要的配置文件格式,主要有以下几个原因:

  • 人类可读性高: YAML 的简洁语法和缩进结构使其比 XML 或 JSON 更容易编写和阅读,尤其是在配置复杂的分布式系统时。
  • 易于版本控制: 基于文本的 YAML 文件非常适合使用 Git 等版本控制系统进行管理、跟踪变更和协作。
  • 丰富的表达能力: YAML 支持标量(字符串、数字、布尔值)、列表和嵌套映射,足以表达 Kubernetes 中各种复杂资源对象之间的关系和配置。
  • 工具支持广泛: YAML 是一种流行的数据格式,有大量编程语言、编辑器和工具提供了对它的解析和处理支持。

虽然 Kubernetes API 内部使用的是 JSON,但 YAML 是其外部表示和用户交互的主要方式。kubectl 工具会自动在 YAML 和 JSON 之间进行转换。

第二部分:Kubernetes 对象的基本结构 (Anatomy of a K8s Object)

每一个 Kubernetes 资源对象(如 Pod、Deployment、Service、ConfigMap 等)在 YAML 文件中都有一个标准的基本结构。理解这个结构是编写任何 Kubernetes YAML 文件的基础。

一个典型的 Kubernetes 对象定义包含以下四个顶级字段:

“`yaml
apiVersion: # 指定创建该对象所使用的 Kubernetes API 版本
kind: # 指定创建的资源对象类型
metadata: # 对象的元数据,如名称、命名空间、标签、注解等
spec: # 期望的对象状态(用户定义)

status: # 当前的对象状态(由 Kubernetes 集群填充和更新,用户通常不在此字段编写内容)

“`

让我们详细解释这四个核心字段:

2.1 apiVersion

  • 用途: 指定你正在使用的 Kubernetes API 版本。Kubernetes 的 API 是版本化的(例如 v1, apps/v1, networking.k8s.io/v1),不同版本的 API 可能支持不同的功能或字段。
  • 重要性: 必须指定正确的 API 版本,否则 Kubernetes 将无法识别你想要创建的对象类型或其字段。你可以在 Kubernetes 文档中查找特定资源类型属于哪个 API 版本。
  • 示例:
    • apiVersion: v1 (用于 Pod, Service, ConfigMap, Secret 等核心对象)
    • apiVersion: apps/v1 (用于 Deployment, StatefulSet, DaemonSet 等工作负载对象)
    • apiVersion: networking.k8s.io/v1 (用于 Ingress)

2.2 kind

  • 用途: 指定你想要创建的 Kubernetes 资源对象的类型。
  • 重要性: 告诉 Kubernetes 你是在定义一个 Pod、一个 Deployment、一个 Service 还是其他什么对象。
  • 示例:
    • kind: Pod
    • kind: Deployment
    • kind: Service
    • kind: ConfigMap

2.3 metadata

  • 用途: 包含对象的元数据,即描述对象本身的信息。
  • 重要性: 用于标识和组织对象,例如通过名称引用对象,通过标签筛选对象,通过命名空间隔离对象。
  • 常见子字段:
    • name (字符串): 对象在命名空间内的唯一名称。必须符合 DNS 子域名规范。
    • namespace (字符串, 可选): 对象所在的命名空间。如果省略,则使用当前上下文的默认命名空间。
    • labels (映射/字典): 一组键值对,用于标识和分组对象。这是 Kubernetes 中非常重要的组织和查找机制(例如 Service 通过 labels 找到 Pods)。
      yaml
      labels:
      app: my-web-app
      tier: frontend
    • annotations (映射/字典): 一组键值对,用于存储任意非标识性的元数据。通常用于工具、库的配置信息,或者人工可读的描述。
      yaml
      annotations:
      description: "This is the main web application deployment."
      maintainer: "[email protected]"
    • uid, resourceVersion, creationTimestamp 等: 这些字段通常由 Kubernetes 集群在对象创建后自动填充,不应手动修改。

2.4 spec

  • 用途: 描述你 期望 对象达到的状态。这是 YAML 文件中最核心、最复杂的部分,你在这里定义了对象的所有配置细节。
  • 重要性: Kubernetes 控制平面(特别是各种控制器)会不断地将集群的 当前状态 (status) 与你在 spec 中定义的 期望状态 进行对比,并采取必要的行动(创建、更新、删除等)来弥合差异。
  • 内容: spec 的具体内容完全取决于 kind 字段定义的资源类型。例如:
    • Pod 的 spec 定义了容器、卷、重启策略等。
    • Deployment 的 spec 定义了副本数、Pod 模板、更新策略等。
    • Service 的 spec 定义了端口映射、选择器、服务类型等。

2.5 status

  • 用途: 描述对象的 当前 状态。这个字段是由 Kubernetes 集群自动填充和更新的。
  • 重要性: 用户主要通过 kubectl get <resource> <name> -o yamlkubectl describe <resource> <name> 命令来查看 status 字段,以了解对象的运行情况(例如 Pod 是否正在运行,Deployment 是否已达到期望的副本数,Service 的 IP 地址是多少等)。
  • 注意: 在编写 YAML 文件提交给 Kubernetes 时,通常不包含 status 字段。你只定义你期望的状态 (spec),集群负责更新实际状态 (status)。

理解了这四个核心字段后,我们就有了编写 Kubernetes YAML 文件的骨架。接下来,我们将通过具体的资源类型来填充这个骨架。

第三部分:核心 Kubernetes 资源类型的 YAML 示例

现在,让我们来看一些最常用、最基础的 Kubernetes 资源类型,并学习如何编写它们的 YAML 文件。

3.1 Pod (apiVersion: v1, kind: Pod)

Pod 是 Kubernetes 中可以创建和管理的最小计算单元。它是一个或一组紧密相关的容器,共享网络命名空间、存储卷等资源。

“`yaml

pod-example.yaml

apiVersion: v1 # API 版本为 v1
kind: Pod # 对象类型为 Pod

metadata: # 元数据
name: my-nginx-pod # Pod 的名称,在当前命名空间下唯一
labels: # Pod 的标签,用于标识和选择
app: nginx
env: dev

spec: # 期望状态
containers: # 定义 Pod 中包含的容器列表
– name: nginx # 容器的名称,在一个 Pod 中必须唯一
image: nginx:1.25 # 容器使用的镜像,格式为 registry/image:tag
ports: # 容器暴露的端口列表
– containerPort: 80 # 容器内部监听的端口
resources: # 容器资源限制和请求
requests: # 资源请求,用于调度
cpu: “100m” # 100 millicpu (0.1 CPU 核心)
memory: “128Mi” # 128 Mebibytes
limits: # 资源限制,防止资源滥用
cpu: “200m” # 200 millicpu (0.2 CPU 核心)
memory: “256Mi” # 256 Mebibytes
restartPolicy: Always # Pod 重启策略,默认是 Always(容器失败时总是重启)
# 其他可选字段:volumes, serviceAccountName, nodeSelector 等
“`

关键点解释:

  • containers: Pod 的核心,是一个列表,因为一个 Pod 可以包含多个容器。每个容器至少需要指定 nameimage
  • ports.containerPort: 容器内部应用监听的端口。这并不会自动在节点或集群外部暴露端口,只是Informational信息,有时会被服务发现机制使用。
  • resources: 定义容器所需的 CPU 和内存资源。requests 用于调度器决定将 Pod 放在哪个节点,limits 用于限制容器使用的最大资源量,防止其影响其他容器或节点稳定性。
  • restartPolicy: 定义 Pod 中容器终止时 Kubernetes 如何处理。Always 会一直尝试重启失败的容器。

如何应用这个 Pod YAML?

bash
kubectl apply -f pod-example.yaml

应用后,Kubernetes 控制平面会根据这个 YAML 文件描述的状态(即创建一个名为 my-nginx-pod 的 Pod)来创建 Pod。

3.2 Deployment (apiVersion: apps/v1, kind: Deployment)

直接管理 Pod 通常不灵活,因为 Pod 是短暂的,如果节点故障,Pod 也会丢失。Deployment 是一种更高级的资源对象,它提供声明式更新 Pods 和 ReplicaSets 的能力。Deployment 可以确保指定数量的 Pod 副本一直在运行,并支持滚动更新、回滚等功能。

“`yaml

deployment-example.yaml

apiVersion: apps/v1 # Deployment 属于 apps/v1 API 版本
kind: Deployment # 对象类型为 Deployment

metadata: # 元数据
name: my-web-deployment # Deployment 的名称
labels:
app: my-web-app # 部署的整体应用的标签

spec: # 期望状态
replicas: 3 # 期望运行的 Pod 副本数量
selector: # 选择器,用于找到由该 Deployment 管理的 Pods
matchLabels: # 通过匹配标签来选择 Pods
app: my-web-app # 这里的标签必须与 Pod 模板中的标签一致
tier: frontend # 这里的标签必须与 Pod 模板中的标签一致
strategy: # 更新策略,默认是 RollingUpdate(滚动更新)
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1 # 更新过程中最多允许一个不可用的 Pod
maxSurge: 1 # 更新过程中最多允许比期望副本数多一个 Pod
template: # Pod 模板,用于创建新的 Pod 副本
metadata: # Pod 模板的元数据
labels: # 这里的标签是创建出来的 Pod 将会拥有的标签
app: my-web-app
tier: frontend
spec: # Pod 模板的期望状态 (这里的 spec 和 Pod 的 spec 结构类似)
containers:
– name: my-web-container
image: nginx:1.25
ports:
– containerPort: 80
resources:
requests:
cpu: “100m”
memory: “128Mi”
limits:
cpu: “200m”
memory: “256Mi”
“`

关键点解释:

  • apiVersion: apps/v1: Deployment 属于 apps/v1 API 组。
  • replicas: 指定你希望运行的 Pod 副本数量。Deployment 控制器会负责启动并维护这个数量的 Pod。
  • selector: 非常重要! Deployment 通过这个选择器找到它需要管理的 Pods。matchLabels 里的标签必须与 template.metadata.labels 里的标签完全一致。这是 Deployment 知道哪些 Pod 属于它的方式。
  • template: 这是一个 Pod 模板。Deployment 使用这个模板来创建新的 Pod 副本。注意template 下的 metadataspec 与独立的 Pod 定义非常相似。template.metadata.labels 定义了由这个 Deployment 创建的 Pod 将会带有的标签,这些标签必须能被上面的 selector 选中。

如何应用这个 Deployment YAML?

bash
kubectl apply -f deployment-example.yaml

应用后,Kubernetes 会创建一个 Deployment 对象,该对象会进一步创建一个 ReplicaSet,然后 ReplicaSet 会按照 replicas: 3template 的定义创建 3 个带有指定标签的 Pod。

3.3 Service (apiVersion: v1, kind: Service)

Pod 的 IP 地址是不稳定的,Pod 可能会因为各种原因被销毁并重新创建,获得新的 IP。Service 资源提供了一个稳定的网络端点(IP 地址和端口),用于访问一组具有相同功能的 Pods。Service 通过 标签选择器 (label selector) 找到它所暴露的 Pods。

“`yaml

service-example.yaml

apiVersion: v1 # Service 属于 v1 API 版本
kind: Service # 对象类型为 Service

metadata: # 元数据
name: my-web-service # Service 的名称
labels:
app: my-web-app # Service 自身的标签

spec: # 期望状态
selector: # 选择器,用于找到 Service 需要暴露的 Pods
app: my-web-app # 这里的标签必须与上面 Deployment 或 Pods 的标签一致
tier: frontend # 这里的标签必须与上面 Deployment 或 Pods 的标签一致
ports: # Service 暴露的端口列表
– protocol: TCP # 协议
port: 80 # Service 自身的端口 (Service ClusterIP/NodePort 端口)
targetPort: 80 # Pods 内部容器监听的端口 (Container Port)
# nodePort: 30080 # 如果 Service 类型是 NodePort,可以指定或由 K8s 自动分配
type: ClusterIP # Service 的类型
# 可选的服务类型:ClusterIP (默认), NodePort, LoadBalancer, ExternalName
“`

关键点解释:

  • selector: 非常重要! Service 使用这个选择器来动态查找匹配标签的所有 Pods。当 Service 接收到请求时,它会将请求转发到这些被选中的 Pods 中的一个。这里的标签通常就是 Deployment 或 Pod 模板中定义的标签。
  • ports: 定义了 Service 暴露的端口以及如何映射到 Pod 的端口。
    • port: Service 自身的端口。其他 Pods 或 Service 可以通过 my-web-service:<port> 访问。
    • targetPort: Pod 中容器实际监听的端口(即 Pod 模板中容器的 containerPort)。
    • protocol: 端口协议,通常是 TCP 或 UDP。
  • type: 定义 Service 的访问方式:
    • ClusterIP (默认): 在集群内部暴露一个稳定的 IP 地址,只能在集群内部访问。
    • NodePort: 在集群内每个节点的固定端口上暴露 Service,可以通过任意节点的 IP:NodePort 从集群外部访问。NodePort 范围通常在 30000-32767。
    • LoadBalancer: 在支持的云平台上创建一个外部负载均衡器,将流量转发到 Service。

如何应用这个 Service YAML?

bash
kubectl apply -f service-example.yaml

应用后,Kubernetes 会创建一个 Service 对象,它会根据 selector 查找匹配的 Pods,并为这些 Pods 提供一个稳定的访问入口。

3.4 ConfigMap (apiVersion: v1, kind: ConfigMap)

ConfigMap 用于存储非敏感配置数据,如应用配置、环境变量、配置文件等。它可以将配置与 Pod 的定义分离,使得应用更加可移植和易于管理。

“`yaml

configmap-example.yaml

apiVersion: v1
kind: ConfigMap

metadata:
name: app-config # ConfigMap 的名称

data: # 存储配置数据的部分 (字符串键值对)
app.properties: | # 可以存储整个文件的内容
database.url=jdbc:mysql://mysql-service:3306/mydb
database.username=myuser
timeout=3000
log_level: “INFO” # 也可以存储单个值
feature_flags: “true,false,true”
“`

关键点解释:

  • data: 存储具体的配置数据。键是字符串,值也是字符串。值可以是简单的文本行,也可以是多行文本(使用 |> 来表示)。
  • ConfigMap 本身不执行任何操作,它只是一个数据存储。你需要通过在 Pod 定义中引用 ConfigMap 来使用这些数据(通常作为环境变量或挂载为文件)。

如何在 Pod 中使用 ConfigMap?

可以通过 envFromvolumeMounts 将 ConfigMap 的数据注入到 Pod 的容器中。

“`yaml

pod-with-configmap.yaml

apiVersion: v1
kind: Pod
metadata:
name: my-app-pod-with-config
spec:
containers:
– name: my-app-container
image: my-app-image:latest
# 方式一:作为环境变量注入单个值
env:
– name: LOG_LEVEL
valueFrom:
configMapKeyRef:
name: app-config # 引用 ConfigMap 的名称
key: log_level # 引用 ConfigMap 中的键

  # 方式二:将 ConfigMap 的键值对作为环境变量注入
  # envFrom:
  #   - configMapRef:
  #       name: app-config

  # 方式三:将 ConfigMap 挂载为文件卷
  volumeMounts:
    - name: config-volume # 卷的名称
      mountPath: "/etc/app/config" # 容器内挂载路径
      readOnly: true # 通常设置为只读

volumes: # 定义 Pod 的卷
– name: config-volume # 卷的名称
configMap: # 卷的类型是 ConfigMap
name: app-config # 引用 ConfigMap 的名称
# items: # 可选:指定 ConfigMap 中哪些键要挂载以及文件名为
# – key: app.properties
# path: app.properties
“`

通过 YAML 定义 ConfigMap,然后在 Pod YAML 中引用它,实现了应用配置与应用逻辑的解耦。

第四部分:使用 kubectl 处理 YAML 文件

编写好 YAML 文件后,你需要使用 Kubernetes 命令行工具 kubectl 将其应用到集群中。

4.1 应用 YAML 文件

使用 kubectl apply -f <filename.yaml> 命令来创建或更新资源对象。apply 命令是声明式的,它会读取 YAML 文件,与集群中现有对象进行比较,然后执行创建或更新操作以达到 YAML 文件描述的期望状态。这是生产环境中推荐的使用方式。

bash
kubectl apply -f pod-example.yaml
kubectl apply -f deployment-example.yaml
kubectl apply -f service-example.yaml
kubectl apply -f configmap-example.yaml

如果你在一个 YAML 文件中定义了多个资源(使用 --- 分隔),apply 命令会按顺序处理文件中的所有资源。

4.2 查看已创建的资源

使用 kubectl get 命令可以查看已经创建的资源。结合 -o yaml 参数可以以 YAML 格式输出资源的当前状态(包括 Kubernetes 填充的 status 字段)。

“`bash
kubectl get pods
kubectl get deployments
kubectl get services
kubectl get configmaps

查看特定资源的 YAML 定义 (包含 status 字段)

kubectl get pod my-nginx-pod -o yaml
kubectl get deployment my-web-deployment -o yaml
kubectl get service my-web-service -o yaml
“`

使用 kubectl describe 命令可以获取资源的详细信息,包括事件、关联的 Pods(对于 Deployment 和 Service)等,这对于排查问题非常有用。

bash
kubectl describe pod my-nginx-pod
kubectl describe deployment my-web-deployment
kubectl describe service my-web-service

4.3 删除资源

使用 kubectl delete -f <filename.yaml> 命令可以删除由该 YAML 文件创建的资源。

bash
kubectl delete -f service-example.yaml
kubectl delete -f deployment-example.yaml
kubectl delete -f pod-example.yaml # 如果 Deployment 还存在,它会自动重建 Pod,所以通常先删除 Deployment
kubectl delete -f configmap-example.yaml

注意: 删除 Deployment 会连同其管理的 ReplicaSet 和 Pods 一起删除。删除 Service 不会删除其关联的 Pods 或 Deployment。

第五部分:编写 Kubernetes YAML 的最佳实践和常见问题

5.1 最佳实践

  • 使用版本控制: 将所有 Kubernetes YAML 文件存储在 Git 仓库中。这样可以跟踪所有配置更改,方便回滚和协作。这通常被称为“GitOps”的核心思想。
  • 组织文件: 按应用、按命名空间、按资源类型或按环境组织你的 YAML 文件。例如:
    my-app/
    ├── dev/
    │ ├── deployment.yaml
    │ ├── service.yaml
    │ └── configmap.yaml
    └── prod/
    ├── deployment.yaml
    ├── service.yaml
    └── configmap.yaml
  • 保持简洁和模块化: 尽量让每个 YAML 文件负责一个或少数相关资源。如果一个应用的配置非常复杂,可以将其拆分成多个文件。使用 --- 分隔符在单个文件中定义多个相关资源也很常见(例如在一个文件中定义 Deployment 和 Service)。
  • 使用标签 (Labels) 进行组织和选择: 合理规划和使用标签是 Kubernetes 的关键。它们用于连接不同的资源(Service->Pods, Deployment->Pods),也用于分组和过滤资源。
  • 不要在 Pod 模板中定义 NodePort Service: Service 应该独立于 Pod 定义,通过标签选择器关联。
  • 为容器配置资源请求和限制: 这对于集群的稳定性和资源利用率至关重要。
  • 使用 Probe (Liveness/Readiness): 在 Pod 模板的容器定义中配置健康检查 (livenessProbe) 和就绪检查 (readinessProbe),帮助 Kubernetes 判断何时重启容器或将流量路由到 Pod。
  • 使用 Namespace 进行隔离: 将不同的应用或环境部署到不同的命名空间中,实现资源和权限的隔离。
  • 利用工具:
    • IDE/编辑器插件: 大多数现代代码编辑器(如 VS Code、JetBrains IDEs)都有 Kubernetes 和 YAML 插件,提供语法高亮、代码补全、错误检查和 linting 功能。
    • kubectl explain 不确定某个字段的用途?可以使用 kubectl explain <ResourceType>.<field>.<subfield> 来查看官方文档解释。例如:kubectl explain Pod.spec.containers.image
    • kubevalkonftest 这些工具可以在将 YAML 文件应用到集群之前进行静态验证,检查语法错误、字段拼写以及是否符合 Kubernetes Schema。

5.2 常见问题和故障排除

  • 缩进错误 (Indentation Errors): YAML 对缩进非常敏感。一个错误的空格或 Tab 混合就可能导致解析失败。使用支持 YAML 的编辑器并配置正确的缩进(通常是 2 个空格)可以避免很多问题。
  • 字段拼写错误: Kubernetes 字段名是严格区分大小写的。常见的错误如 replicas 写成 replicacontainerPort 写成 containerport 等。kubectl explain 是你的好帮手。
  • API 版本或 Kind 错误: 确保 apiVersionkind 正确匹配。例如,旧版本的 Deployment 可能使用 extensions/v1beta1apps/v1beta1,但现在应该是 apps/v1
  • 选择器不匹配 (Selector Mismatch): 这是 Service 或 Deployment 无法找到其目标 Pod 的最常见原因。确保 selector 中的标签与 Pod 模板 (template.metadata.labels) 中的标签完全一致。标签名称和值都必须匹配。
  • 镜像拉取失败 (ImagePullBackOff): 容器镜像拉取失败可能因为:
    • 镜像名称或标签错误。
    • 私有仓库需要认证但未配置 Secret。
    • 网络问题无法访问镜像仓库。
    • 查看 Pod 的 status 和事件 (kubectl describe pod <pod-name>) 可以找到具体原因。
  • 资源未找到 (NotFound): 当你尝试查看、删除或描述一个不存在的资源时会发生。检查资源名称和命名空间是否正确。
  • applycreate 报错: 错误信息通常会指示问题所在(如解析错误、验证失败等)。仔细阅读错误信息。

第六部分:总结与展望

通过本文的学习,你应该已经掌握了 Kubernetes YAML 的基础知识:

  • 理解了 YAML 的基本语法和它在 Kubernetes 中的作用。
  • 熟悉了 Kubernetes 对象的基本结构:apiVersion, kind, metadata, spec
  • 学习了如何编写 Pod, Deployment, Service, ConfigMap 这几种核心资源对象的 YAML 文件。
  • 了解了如何使用 kubectl apply, get, describe, delete 命令与 YAML 文件交互。
  • 掌握了一些编写 YAML 的最佳实践和常见问题排除技巧。

YAML 是通往 Kubernetes 世界的钥匙。虽然刚开始接触时可能会觉得字段繁多、层级复杂,但随着实践的增多,你会发现其结构化和声明式的特性正是 Kubernetes 强大和可管理的关键。

这仅仅是 Kubernetes 资源的冰山一角。除了 Pod, Deployment, Service, ConfigMap,还有 StatefulSet, DaemonSet, Job, CronJob, Volume, Secret, Ingress, NetworkPolicy, Role, RoleBinding, CustomResourceDefinition (CRD) 等众多资源类型,它们都有各自的 YAML 配置方式。学习这些资源类型的 YAML 定义将帮助你构建更复杂、更强大的云原生应用。

继续实践,动手编写和修改 YAML 文件,并使用 kubectl 与集群互动。通过不断地尝试和调试,你会越来越熟练地运用 Kubernetes YAML,从而更好地驾驭你的容器化应用。

祝你在 Kubernetes 的旅程中一切顺利!

发表评论

您的邮箱地址不会被公开。 必填项已用 * 标注

滚动至顶部