原创

本博客原创文章，转载请注明出处

- name: 原创
  desc: 本博客原创文章，转载请注明出处
  bgColor: '#F0DFB1'
  textColor: '#1078E6'

第3章-基础操作

在本章中将介绍 K8s 的一些基础操作命令。

本章要点
了解及管理命名空间
查看 Pod 及节点的负载
添加及删除worker

11. 一些常用查询指令

1.11.1 完整集群信息

运行以下命令 可以看到集群的精简信息，Kubernetes 主控端运行在 192.168.80.10 主机的 6443 端口上：

kubectl cluster-info

如果添加dump参数，将会以 json 格式打印完整的集群信息。

由于完整的信息量过于庞大，所以此处使用输出重定向，把信息保存在1.json文件中，然后通过 vim 打开这个文件：

kubectl cluster-info dump > 1.json

vim 1.json

如图所示，这些信息有助于 排查错误。

1.21.2 集群版本信息

运行 version 命令将会打印集群的版本信息。

如果添加--short标志符，将会打印精简信息。

kubectl version

kubectl version --short

如图所示，Kubernetes 的版本为 v1.26.5，Golang 的版本为 1.19.9，平台为 amd64 架构的 linux 操作系统...等信息。

在使用--short标志符的同时还打印了一条提升信息：“标志 --short 已被弃用，将来会被删除，--short 的输出将成为默认值”。真是越来越精简了！

1.31.3 集群所支持的API版本信息

通过调用 Kubernetes API 可以实现不同的功能，例如自动创建 Pod、创建网络策略等。

在之后的章节中，将会详细介绍如何创建和运用这些组件。

kubectl api-versions

列出当前 Kubernetes 版本所支持的 API 版本信息：

22. Kubernetes命名空间

2.12.1 Kubernetes中的命名空间是什么？

这里拿我们常用的 社交软件 举个例子。假设现在有 2 个群聊，每个群聊中分别有 3 个用户，每位用户又分别位于不同的城市：

• 群聊-1
  • A 用户（北京）
  • B 用户（上海）
  • C 用户（广州）
• 群聊-2
  • x 用户（北京）
  • y 用户（上海）
  • z 用户（广州）

用户在同一个群聊里 可以无障碍地聊天，群聊与群聊之间是相互隔离的，A 用户和 x 用户虽然都在北京，但他们之间并没有什么交集。

假如把 命名空间 看作一个个不同的群聊：

• 命名空间-1
  • Pod-1（worker1）
  • Pod-2（worker2）
  • Pod-3（worker3）
• 命名空间-2
  • Pod-a（worker1）
  • Pod-b（worker2）
  • Pod-c（worker3）

Pod 在同一个命名空间里 可以无障碍地通信和交互，命名空间 与 命名空间之间是相互隔离的，Pod-1 和 Pod-a 虽然都运行在 worker1 主机上，但它们之间并没有什么交集。

简单来讲，命名空间就是把存在联系的 Pod 划分为一个整体，不相干的整体之间则相互隔离。

2.22.2 Kubernetes中的默认命名空间

查看当前有多少命名空间：

kubectl get namespaces

# 简写
kubectl get ns

从图中可以看到，目前存在 4 个命名空间。这些命名空间都是部署 kubernetes 时自动创建的，也就是内置的命名空间。其中，你将会经常与default和kube-system这两个命名空间打交道。

2.32.3 查看不同命名空间中的pod

查看当前有多少 pod：

kubectl get pods

提示 “在default命名空间中找不到资源”，说明默认的命名空间中没有任何 pod。

使用标志符指定一个命名空间：

kubectl get pods --namespace kube-system

# 简写
kubectl get pods -n kube-system

成功列出kube-system命名空间中的所有 pod。

kube-system命名空间中的 pod 都是与 kubernetes 集群的运行有关的，例如以 “calico-” 开头的 pod 是用于实现 pod 跨主机通信的，名称中带有 “www.k10.com” 的 pod 则是主控节点用于控制、分发和调度任务的，以 “metrics-server-” 开头的 pod 是用于监控集群资源使用情况的......等。

2.42.4 查看Pod及节点的负载

提示

在查询 Pod 或节点的负载信息之前，必须先安装监控类插件，例如 metrics-server。在 2.4 章节中已经演示过 metrics-server 的安装过程，还没有安装的小伙伴可以移步上一章节，先将监控插件装上。

2.4.12.4.1 Pod负载信息

默认命名空间中没有任何 pod，自然也就没有负载信息。

查看kube-system命名空间中所有 pod 的负载：

kubectl top pods -n kube-system

可以看到三列内容，分别是 pod 名称以及对应的 CPU 使用情况、内存使用情况。

此外，你还可以使用--sort-by标志符，对结果进行降序排序：

# 根据 CPU 使用情况进行排序
kubectl top pods -n kube-system --sort-by cpu

# 根据 内存 使用情况进行排序
kubectl top pods -n kube-system --sort-by memory

CPU 排序效果：

内存排序效果：

2.4.22.4.2 节点负载信息

命名空间只作用于 pod 一类的资源，不影响集群内的节点，所以在执行命令时不需要指定命名空间：

kubectl get nodes

kubectl top nodes

2.52.5 创建、切换及删除命名空间

创建命名空间：

kubectl create namespace <名称>

# 简写
kubectl create ns <名称>

命名空间的名称不能随意指定，需要遵循命名规范——只能是 数字、小写字母和-符号。

如图所示，成功创建了一个名为this-is-new-ns的命名空间。

切换命名空间：

• --current：选择当前集群
• --namespace：指定要切换的命名空间

# 切换到 指定集群 的某个命名空间
kubectl config set-context <集群名称> --namespace <命名空间名称>

# 切换到 当前集群 的某个命名空间
kubectl config set-context --current --namespace <命名空间名称>

从图中可以看到，先执行了一次kubectl get pods，此时提示 “未在default命名空间中找到资源”。

然后将当前的命名空间切换为kube-system，再次进行 pod 查询操作，成功列出了kube-system命名空间中的所有 pod。在这之前，我们每次查询 pod 都需要添加标志符-n kube-system，但现在不需要了。

说明kubectl get pods这类命令并不是围绕default命名空间来执行的，而是围绕用户当前所处的命名空间。

删除命名空间：

kubectl delete namespaces <名称>

# 简写
kubectl delete ns <名称>

删除成功，第二次查询中已经没有了 this-is-new-ns 命名空间的踪迹。

33. 删除节点并重新加入集群

有时，我们需要把 kubernetes 中的某个节点移除。

现在，让我们尝试从集群中移除 worker2 节点。

第一步，将worker2设置成维护模式

在设置之前，先查看一下节点信息，此时 worker2 的状态为 Ready。

将 worker2 设置成维护模式，并驱逐上面运行的 pod：

• --force：强制执行
• --ignore-daemonsets：忽略其上的 DaemonSet 控制器，之后的章节中会详细介绍
• --delete-emptydir-data：清除 pod 在主机存储中保存的本地数据

原本运行在 worker2 上的 pod 将会被驱逐至其他工作节点上继续运行。

# 有时候不添加 --delete-emptydir-data 也能执行成功
kubectl drain www.k12.com --force --ignore-daemonsets --delete-emptydir-data

kubectl get nodes

再次查看节点信息，发现 worker2 多了一个状态 “SchedulingDisabled”，说明 worker2 已经被停止调度，后续的工作任务将不会被派发给 worker2。

第二步，从集群中删除worker2

使用 delete nodes 命令彻底删除这个节点：

kubectl delete node www.k12.com

kubectl get nodes

再次查看节点信息，此时已经看不到 worker2 的踪迹了。

第三步，清空worker2上的配置

转到 worker2 所在的主机，运行以下命令并输入 “y” 进行确认，重置所有 kubernetes 设置。

• 只会清空配置信息，并不是整个 kubernetes 都给你卸了
• 不管是 master 还是 worker 主机，如果想重置 kubernetes 设置的话，都需要执行kubeadm reset命令

kubeadm reset

第四步，重新加入集群

哎呀，加入集群的命令是什么来着？忘记了怎么办？

没关系，我们可以在 master 节点上使用 kubeadm 获取一个新的 “加入集群” 命令：

kubeadm token create --print-join-command

回到 worker2 并运行新获得的加入命令，执行命令的过程中出现错误。

错误信息：“/proc/sys/net/bridge/bridge-nf-call-iptables不存在”。

这个错误信息中的路径，看起来是不是很眼熟？

在 1.6 章节中，我们对主机进行了内核参数配置，刚刚在执行kubeadm reset的过程中 配置可能被清掉了，现在重新运行一遍配置命令，用以设置主机内核参数。

# 设置内核的网络参数
cat <<EOF > /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
EOF

# 加载br_netfilter模块
modprobe br_netfilter

# 让新的内核配置立即生效
sysctl -p /etc/sysctl.d/k8s.conf

重新加入集群，这一次没有报错。

在 master 上查看节点信息，worker2 在 32 秒之前加入了集群，说明刚刚的加入操作成功了。

3.53.5 重新加入集群时，可能会遇到的各种错误

3.5.13.5.1 缺少内核参数

这个错误在 “第四步” 中已经遇到过了，只需要重新设置一下内核参数即可：

# 设置内核的网络参数
cat <<EOF > /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
EOF

# 加载br_netfilter模块
modprobe br_netfilter

# 让新的内核配置立即生效
sysctl -p /etc/sysctl.d/k8s.conf

3.5.23.5.2 清空配置不彻底

在 “第三步” 中，从集群删除 worker2 之后，我们曾在 worker2 上执行kubeadm reset命令，用以清空主机上所有旧的 kubernetes 设置。

这种清空方式 有时候会出现清除不彻底的情况，需要我们手动再清除一遍。

如果再次加入集群时 出现了这类错误的话，只需要把/etc/kubernetes/pki/和/var/lib/kubelet/这两个目录下的内容都清空，然后再次加入集群即可。注意，是删除这两个目录中的内容，而不是删除这两个目录。你可以通过以下命令来实现这个效果：

rm -rf /etc/kubernetes/pki/*
rm -rf /var/lib/kubelet/*

44. 小结

在本章中，我们介绍了 Kubernetes 的一些常见命令、如何管理命名空间，以及如何删除节点并使其重新加入集群。

我为你准备了一点课后练习（练习题-1），以帮助你掌握前面所学的知识点，快去试试吧！