一、Kubectl命令行工具

1. kubectl命令用法

kubectl命令行的语法如下所示：

kubectl [command] [TYPE] [NAME] [flags]

• command：指定要对一个或多个资源执行的操作，例如create、delete、get、describe、apply、edit等

• TYPE：指定资源类型，资源类型不区分大小写，可以指定单数/复数/缩写方式

  • 以下三种书写格式效果均一致

  • kubectl get pod pod01

  • kubectl get pods pod01

  • kubectl get po pod01

• NAME：指定资源名称，名称区分大小写；如果不指定名称，则返回该TYPE下的全部对象

• flags：指定可选参数，例如可以使用“-s”或“-server”参数指定Kubernetes API服务器的地址和端口

2. kubectl命令解析

2.1 kubectl基础命令解析

2.2 故障处理与诊断命令

2.3 集群管理命令

2.4 高级管理命令

2.5 设置命令

2.6 其它命令

3. kubectl命令参数flags

[Step1] 可以在Master上使用命令列出可以全局使用的命令参数。

root@k8s-master:~# kubectl options

4. kubectl输出格式

kubectl命令可以以多种格式对结果进行显示，输出的格式通过“-o”参数进行指定。

kubectl [command] [TYPE] [NAME] -o=<输出格式>

针对不同子命令的输出结果，可选的输出格式如下所示

二、YAML语法

1. YAML语法编写规范

1. 大小写敏感

2. 使用缩进来表示层级关系

3. 缩进时不允许使用Tab键，只允许使用空格（两个空格）

4. 注释符为“#”，从该字符到行尾，都会被解释器忽略

5. 列表项以“-”加一个空格表示，多个项使用同级缩进来表示同一列表部分

6. 键值对用“:”冒号来分割

7. 文件一般以“yml”或“yaml”作为后缀名

2. YAML文件结构

[Step1] 键值对格式：YAML文件中的基本类型是键值对，键值对的格式为“键: 值”。

# 键: 值，冒号后面必须加上空格
name: nginx

[Step2] 块式列表：列表的元素以“-”开头，同一个列表下的所有元素，缩进必须一致。

# JSON格式为：{"fruits":["Apple","Orange"]}
fruits:
  - Apple
  - Orange

[Step3] 列表元素不止包含一个值，还可以是一组键值对。1个对象，多个属性。

# JSON格式为：{"containers":[{"name":"nginx","image":"nginx:alpine"}]}
containers:
  - name: nginx
    image: nginx:alpine

[Step4] 多个独立对象，多个元素。

# JSON格式为：{"containers":[{"name":"nginx"},{"name":"redis"}]}
containers:
  - name: nginx
  - name: redis

[Step5] 字典/地图：YAML文件中更复杂的类型是字典和地图。

# JSON格式为：{"containers":{"name":"nginx","cpu":"kunpeng"}}
containers:
  name: nginx
  cpu: kunpeng

3. 增强列表可读性

[Step1] Kubernetes官网文档中的YAML文件示例，其实可以看到对于列表项，是没有缩进的。在语法上，这没有任何问题，但是在加上缩进会更利于阅读。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

[Step2] 在列表项前加上缩进后的效果，与Step1对比会更利于阅读。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:1.14.2
      ports:
        - containerPort: 80

4. explain子命令查询层级关系

在上面的YAML文件示例中，能够看到参数的层级关系。例如：“metadata”下的“name”，“spec”下的“containers”。每一层下都可能存在多个可选值，而可选值下可能又会存在可选值。层级关系是无法完全记住的，因此可以通过explain命令来查询可选参数。需要注意的是，在查询过程中每个层级之间的都要加上“.”。

[Step1] 查询metadata下的可选值。

root@k8s-master:~# kubectl explain namespace.metadata

5. 生成YAML文件框架

如果有学习过Ansible，应该知道在Ansible中能够查询到一些常用的、基本的模版，只需要复制粘贴后修改，即减少了撰写时间，也可以一定程度减少文件格式问题。在Kubernetes中，也同样提供了类似的方式。

[Step1] 通过在创建资源时加上“--dry-run=client -o yaml”来生成YAML文件框架。默认情况下，只会输出到控制台。

root@k8s-master:~# kubectl create deployment mydeploy --image=nginx --dry-run=client -o yaml

[Step2] 也可以通过重定向的方式输出到指定文件中。

root@k8s-master:~# kubectl create deployment mydeploy --image=nginx --dry-run=client -o yaml > nginx.yaml

6. apiVersion

apiVersion按迭代层级划分为：Alpha（实验版）、Beta（预发布）、Stable（稳定版）

4.1 Alpha

版本标识含alpha，属于实验性版本。此类版本大概率存在功能缺陷，启用相关功能易引发运行异常。其支持的功能可不经通知随时移除，API也可能发生不兼容变更，且官方不会进行版本变更告知。因漏洞风险较高、无长期维护支持，仅建议用于短期集群测试，严禁在生产环境部署使用。

4.2 Beta

版本标识含beta，代码已完成基础测试，启用功能整体运行安全可靠。已上线功能不会被整体移除，但细节仍可调整；资源字段格式、使用规范及功能逻辑，可能在后续Beta版或正式版中发生不兼容变更。建议应用于非核心业务场景；若拥有多套可独立升级的集群，可酌情部署使用。

4.3 Stable

版本格式为vX（X为整数）。稳定功能会长期纳入后续官方发行版本，社区也常将其称作正式版、GA版、功能毕业。

7. 资源对象列表

[Step1] 可以在Master上使用命令显示可用的资源对象。

root@k8s-master:~# kubectl api-resources

8. 扩展CRD资源

CRD（Custom Resource Definition，自定义资源定义）是Kubernetes提供的一种扩展机制，允许用户通过YAML文件定义自定义资源类型，并将其注册到Kubernetes API中，使其与内置资源（如Pod、Deployment）一样被管理。

• 本质：CRD是对自定义资源的元数据描述，定义了资源的名称、结构、版本、作用域等

• 作用：扩展 Kubernetes API，支持用户自定义资源的管理和自动化操作

CRD核心字段

三、Namespace

1. 命名空间

Kubernetes支持在同一个物理集群上划分出多个逻辑虚拟集群，这类逻辑隔离单元称为命名空间。命名空间适用于多团队、多项目共用集群的业务场景，核心作用是为资源名称提供独立作用域。同一个命名空间内的资源名称必须唯一，不同命名空间允许重名。命名空间不支持嵌套，任何Kubernetes资源仅能归属单个命名空间。同时，命名空间也是多用户、多团队之间按资源配额划分集群资源的核心实现方式。

[Step1] 通过“kubectl api-resources”查看到的结果能够看到“NAMESPACED”列，该参数为布尔值。其中“true”表示资源在特定范围内可见，“false”则表示在集群中可见。

root@k8s-master:~# kubectl api-resources

2. 新增NAMESPACE

2.1 通过命令方式创建

[Step1] 通过命令查看当前K8s集群中所有的命名空间。

root@k8s-master:~# kubectl get namespaces
root@k8s-master:~# kubectl get ns		// 缩写形式

[Step2] 通过命令新增NAMESPACE。

root@k8s-master:~# kubectl create namespaces demo-ns
root@k8s-master:~# kubectl create ns demo-ns

[Step3] 如果未指定NAMESPACE，则默认为“default”。

root@k8s-master:~# kubectl get pod
root@k8s-master:~# kubectl get pod -n kube-system

2.2 通过YAML方式修改

[Step1] 本地创建一个YAML文件。

root@k8s-master:~# vim namespace.yaml

# 写入下列内容
apiVersion: v1
kind: Namespace
metadata:
  name: yaml-ns

[Step2] 根据YAML文件创建k8s资源。

root@k8s-master:~# kubectl create -f namespace.yaml

[Step3] 验证：查看本地的NAMESPACE资源，能够看到刚刚创建的“yaml-ns”。

[Step4] 有时候可能无法记住YAML中各类键值，可以通过“explain”参数进行查询。

root@k8s-master:~# kubectl explain namespace

[Step5] 有时候可能也会疑惑，“kind”后的参数是否需要大写，可以查询“api-resources”找到结果。

// -i参数忽略大小写
root@k8s-master:~# kubectl api-resources | grep -i namespace

[Step5] 如果不清楚“metadata”下可以加什么参数，同样可以通过“explain”参数进行查询。

root@k8s-master:~# kubectl explain namespace.metadata

3. 修改默认NAMESPACE

[Step1] 设置命名空间偏好。

root@k8s-master:~# kubectl config set-context --current --namespace=testns

[Step2] 查看当前kubectl客户端的配置信息，过滤出空间偏好。

root@k8s-master:~# kubectl config view | grep namespace

[Step3] 在删除NAMESPACE时，如果当前空间偏好为删除对象，此时可能会卡住，等待一段时间可能会失败也可能删除。在生产环境中，建议先将命名空间偏好切换后，再执行删除动作。

root@k8s-master:~# kubectl delete namespaces testns

四、CRD自定义资源

1. CRD概述

CRD（Custom Resource Definition）是Kubernetes的一种API扩展机制，核心作用是在不修改K8s核心代码的前提下，让管理员能够自定义全新的资源类型，并像管理Pod、Service一样用kubectl进行管理。 CRD是资源的定义模版，属于K8s内置资源（apiextensions.k8s.io/v1），描述新资源的名称、API组、版本、作用域、数据结构与校验规则。

需要注意的是，CRD本身只定义了资源的结构和API，它不会直接执行任何创建、更新或删除操作。这些操作需要通过一个控制器（Controller）来实现。控制器是一个独立的程序，它监听CRD的变化，并根据这些变化执行实际的操作。

1.1 为什么需要CRD

• 扩展Kubernetes API：Kubernetes的原生资源可能无法满足所有用户的需求，CRD允许用户定义自己的资源类型，从而扩展Kubernetes的管理功能

• 管理复杂应用：有些应用可能需要管理一些特定的资源，这些资源不属于Kubernetes原生支持范围。通过CRD，能够将这些资源纳入Kubernetes的管理范围，实现统一的资源管理。

1.2 CRD的作用

• 定义资源结构：CRD允许定义资源的结构，包括字段和数据类型

• 管理资源生命周期：Kubernetes将管理这些自定义资源的生命周期，包括创建、更新、删除等操作

• 集成Kubernetes生态系统：CRD可以与Kubernetes的其他组件（如控制器、操作符等）集成，实现更复杂的业务逻辑

[Step1] 查看当前系统中存在的自定义资源。

root@k8s-master:~# kubectl get crd

2. 创建自定义CRD与API资源

[Step1] 编写一个YAML文件，创建自定义CRD资源。

root@k8s-master:~# vim democrd.yaml

# 写入下列内容
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  # 名称必须和[spec]字段相匹配，且格式为[名称的复数形式.组名]
  name: democrds.stable.example.com
spec:
  # 组名，用于REST API：/apis/组/版本
  group: stable.example.com
  # 列举CustomResourceDefinition支持的版本
  versions:
    - name: v1
      # 每个版本都可以通过served来独立启用或禁止
      served: true
      # 标记为存储版本，只能存在一个
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
              	# 自定义字段
                demoAAA:
                  type: string
                demoBBB:
                  type: string
                demoCCC:
                  type: integer
  # 可以是Namespaced或Cluster
  # 如果[scope: Namespaced]，则[kubectl api-resources]中该资源的[NAMESPACED]置为true
  # 如果[scope: Cluster]，则[kubectl api-resources]中该资源的[NAMESPACED]置为false
  scope: Namespaced
  names:
    # 名称的复数形式，用于 URL: /apis/组/版本/名称的复数形式
    plural: democrds
    # 名称的单数形式，作为命令行使用时和显示时的别名
    singular: democrd
    # kind通常是单数形式的驼峰命名形式，资源清单会使用这一形式
    kind: CronTab
    # 允许在命令行中使用的缩写
    shortNames:
      - dm

[Step2] 将自定义CRD资源注册为API资源。

root@k8s-master:~# kubectl apply -f democrd.yaml

[Step3] 验证：此时能够查看到自定义的CRD资源。

root@k8s-master:~# kubectl get crd

[Step4] 验证：查看当前集群中所有可操作的资源，能够看到自定义的CRD资源，且可以看到“NAMESPACED”为“true”。

root@k8s-master:~# kubectl api-resources

[Step5] 验证：能够通过“explain”查询到自定义CRD资源字段说明，其中“spec”字段显示“no description”是因为我们没有添加相关描述信息。

root@k8s-master:~# kubectl explain democrd

[Step6] 验证：进一步查看资源字段说明，能够看到自定义的字段信息。自定义字段的描述信息同样显示为“no description”，还是因为我们没有添加描述信息。

root@k8s-master:~# kubectl explain democrd.spec

[Step7] 如果要给字段添加上描述信息，修改YAML文件，在对应字段下添加“description”参数。

root@k8s-master:~# vim democrd.yaml

# 在需要加上描述信息的字段下面添加description
demoAAA:
  type: string
  description: "This is a test field"

[Step8] 更新资源，重新查看自定义CRD资源字段说明，能够看到自定义字段“demoAAA”已经更新了描述信息。

root@k8s-master:~# kubectl explain democrd.spec