手把手教你安装 Kubernetes – wiki基地

作者： /

手把手教你搭建高可用 Kubernetes 集群 (基于 kubeadm)

Kubernetes (K8s) 已经成为容器编排的事实标准，它极大地简化了容器化应用的部署、扩展和管理。无论是学习容器技术、构建微服务平台，还是部署生产环境应用，掌握 Kubernetes 的安装与配置都是必不可少的第一步。

本篇文章将手把手地引导你完成一个基于 kubeadm 工具的多节点 Kubernetes 集群安装过程。我们将专注于使用 Ubuntu Server 操作系统，并详细讲解每个步骤的意义和操作方法，确保即使是初学者也能成功搭建起自己的 K8s 环境。

本文目标：

  • 了解使用 kubeadm 安装 Kubernetes 的基本流程。
  • 掌握在 Ubuntu 系统上进行 Kubernetes 安装前的环境准备。
  • 成功安装一个包含一个控制平面节点 (Control Plane) 和多个工作节点 (Worker Node) 的 Kubernetes 集群。
  • 配置网络插件， enabling Pod 之间的通信。
  • 验证集群的健康状态，并部署一个简单的应用进行测试。

适用范围：

  • 适用于在虚拟机（如 VirtualBox, VMware, KVM）、云服务器（如 AWS EC2, Aliyun ECS）或物理机上搭建 K8s 集群。
  • 操作系统：Ubuntu 20.04 LTS 或 Ubuntu 22.04 LTS。
  • Kubernetes 版本：我们将使用撰写本文时较新的稳定版本（例如 1.28 或 1.29，具体取决于仓库提供的版本），但安装流程对于不同版本通常差异不大。

环境准备：

在开始之前，你需要准备至少两台运行 Ubuntu Server 的机器（虚拟机或物理机）。一台将用作控制平面节点，另一台或多台将用作工作节点。

对于本指南，我们假设你准备了三台机器：

  • k8s-control-plane: 作为控制平面节点
  • k8s-worker-1: 作为工作节点 1
  • k8s-worker-2: 作为工作节点 2

每台机器的最低配置要求：

  • 操作系统: Ubuntu 20.04+ Server 64-bit
  • 内存: 至少 2GB (控制平面节点建议 4GB+)
  • CPU: 至少 2 核 (控制平面节点建议 4 核+)
  • 硬盘: 至少 20GB 可用空间
  • 网络: 所有机器之间必须能够相互访问（特别是控制平面节点与工作节点之间），且所有机器都应能够访问互联网（用于下载安装包和镜像）。
  • 用户权限: 一个拥有 sudo 权限的用户。

重要提示：

  • 本文是基于 kubeadm 的基础安装指南，旨在帮助理解 K8s 的组件和安装过程。 对于生产环境，还需要考虑高可用控制平面、存储方案、监控、日志、安全加固等更多因素。
  • 请在所有节点上执行标记为 “在所有节点上执行” 的步骤。
  • 请在特定节点上执行标记为 “仅在控制平面节点执行” 或 “仅在工作节点执行” 的步骤。

第一步：在所有节点上进行系统初始化与配置

这一步将在所有参与 Kubernetes 集群的机器上执行，包括控制平面节点和所有工作节点。

1.1 更新系统包

在开始安装 Kubernetes 组件之前，最好先更新操作系统到最新状态。

“`bash

在所有节点上执行

sudo apt update
sudo apt upgrade -y
“`

等待更新完成。如果更新涉及内核等重要组件，可能需要重启机器。建议重启以确保所有更改生效。

“`bash

如果进行了重要更新，建议重启

sudo reboot
“`

1.2 配置主机名与 hosts 文件 (重要)

为了方便管理和识别集群中的节点，建议给每台机器设置一个有意义的主机名，并在 /etc/hosts 文件中添加所有节点的 IP 地址和主机名的映射。这将有助于节点间的名称解析。

假设你的机器 IP 和主机名如下：

  • k8s-control-plane: 192.168.1.100
  • k8s-worker-1: 192.168.1.101
  • k8s-worker-2: 192.168.1.102

设置主机名：

在对应的机器上执行以下命令：

“`bash

在 k8s-control-plane 节点执行

sudo hostnamectl set-hostname k8s-control-plane

在 k8s-worker-1 节点执行

sudo hostnamectl set-hostname k8s-worker-1

在 k8s-worker-2 节点执行

sudo hostnamectl set-hostname k8s-worker-2
“`

修改 /etc/hosts 文件：

在所有节点上，编辑 /etc/hosts 文件：

“`bash

在所有节点上执行

sudo nano /etc/hosts
“`

在文件末尾添加所有节点的 IP 和主机名映射：

192.1668.1.100 k8s-control-plane
192.168.1.101 k8s-worker-1
192.168.1.102 k8s-worker-2

保存并关闭文件。现在，所有节点应该能够通过主机名相互 ping 通。

“`bash

在任意节点上测试 ping

ping k8s-worker-1
ping k8s-control-plane

等等，确保都能解析到正确的 IP

“`

1.3 关闭 Swap (重要)

Kubernetes 官方要求关闭 Swap，因为在使用 Swap 的系统中，Kubelet 会出现问题。你可以通过以下命令临时关闭，并修改 /etc/fstab 文件使其永久生效。

“`bash

在所有节点上执行

临时关闭

sudo swapoff -a

永久关闭：编辑 /etc/fstab 文件

找到包含 swap 的行，在行首添加 # 注释掉

sudo sed -i ‘/ swap / s/^(.*)$/#\1/g’ /etc/fstab
“`

验证 Swap 是否已关闭：

“`bash

在所有节点上执行

free -m

输出中的 Swap 行应该都是 0

“`

1.4 配置内核参数 (重要)

Kubernetes 需要一些特定的内核参数来正常工作，主要是关于网络桥接和 IPv4 转发。我们需要加载 br_netfilter 模块，并配置 sysctl。

“`bash

在所有节点上执行

1. 加载 br_netfilter 模块，并使其开机加载

sudo modprobe br_netfilter
echo ‘br_netfilter’ | sudo tee /etc/modules-load.d/k8s.conf

2. 配置 sysctl 参数

cat <<EOF | sudo tee /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

3. 应用 sysctl 参数

sudo sysctl –system
“`

验证内核参数是否已应用：

“`bash

在所有节点上执行

sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables net.ipv4.ip_forward

应该输出对应参数的值为 1

“`

1.5 安装容器运行时 (Container Runtime)

Kubernetes 不直接运行容器，它依赖于一个容器运行时接口 (CRI)。Docker、containerd、CRI-O 都是常见的运行时。Kubernetes 推荐使用符合 CRI 标准的运行时，如 containerd 或 CRI-O。这里我们选择安装和配置 containerd。

“`bash

在所有节点上执行

1. 安装 containerd

sudo apt update
sudo apt install -y containerd

2. 生成 containerd 默认配置文件并覆盖现有文件

注意：这会覆盖可能已存在的自定义配置，如果已有配置需谨慎

sudo mkdir -p /etc/containerd
sudo containerd config default | sudo tee /etc/containerd/config.toml

3. 修改 containerd 配置，使用 systemd 作为 Cgroup Driver

这是 kubelet 推荐的配置方式，确保 kubelet 和 containerd 使用相同的 Cgroup Driver

编辑 /etc/containerd/config.toml 文件

找到 [plugins.”io.containerd.grpc.v1.cri”.containerd.runtimes.runc.options]

将 SystemdCgroup = false 改为 SystemdCgroup = true

sudo sed -i ‘s/SystemdCgroup = false/SystemdCgroup = true/g’ /etc/containerd/config.toml

4. 重启 containerd 服务使配置生效

sudo systemctl restart containerd

5. 验证 containerd 状态

sudo systemctl status containerd

确保服务是 active (running) 状态

“`

1.6 添加 Kubernetes APT 仓库

Kubernetes 官方提供了 APT 仓库，方便我们在 Ubuntu 上安装 kubeadm, kubelet, kubectl。

“`bash

在所有节点上执行

1. 安装必要的包以允许 apt 通过 HTTPS 使用仓库

sudo apt update
sudo apt install -y apt-transport-https ca-certificates curl

2. 下载 Google Cloud 公钥

sudo curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.29/deb/Release.key | sudo gpg –dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg

3. 添加 Kubernetes apt 仓库

echo “deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.29/deb/ /” | sudo tee /etc/apt/sources.list.d/kubernetes.list

4. 更新 apt 索引

sudo apt update
“`

注意: 上述命令中的 v1.29 是撰写本文时的最新稳定版本示例。你可能需要根据实际情况或你的需求调整版本号。你可以访问 https://pkgs.k8s.io/core:/stable:/ 查看可用的版本。

1.7 安装 Kubeadm, Kubelet 和 Kubectl

现在我们可以从刚刚添加的仓库安装 Kubernetes 的核心组件了。

  • kubeadm: 用于初始化集群和加入节点。
  • kubelet: 运行在所有节点上，是节点上的主要代理，负责 Pod 的创建、终止等。
  • kubectl: 命令行工具，用于与集群进行交互。

“`bash

在所有节点上执行

sudo apt update
sudo apt install -y kubelet kubeadm kubectl

验证安装

kubeadm version
kubectl version –client
“`

为了防止在未来的系统更新时不小心升级 Kubernetes 组件导致兼容性问题，建议将这三个包锁定版本。

“`bash

在所有节点上执行

sudo apt-mark hold kubelet kubeadm kubectl
“`

1.8 关闭防火墙 (建议在学习环境执行)

为了简化安装过程和避免网络问题，特别是对于初学者，建议在学习环境中关闭防火墙（如 ufw）。在生产环境中，应该配置防火墙规则以允许必要的端口流量通过。

Kubernetes 需要开放的端口列表非常多，尤其是在控制平面节点。关闭防火墙能排除端口问题对安装的干扰。

“`bash

在所有节点上执行

检查防火墙状态

sudo ufw status

如果防火墙是激活的，则关闭它

sudo ufw disable

警告：这会使你的机器暴露在网络中，仅在安全的环境或测试中使用。

“`

如果不想关闭防火墙，你需要确保以下端口在节点之间是开放的：

  • 控制平面节点:
    • Inbound: 6443 (Kubernetes API Server)
    • Inbound: 2379-2380 (etcd server client API)
    • Inbound: 10250 (Kubelet API)
    • Inbound: 10251 (Kube-scheduler)
    • Inbound: 10252 (Kube-controller-manager)
    • Inbound: CNI 插件所需的端口 (例如 Calico 默认需要 10250, 4789, 端口范围 30000-32767 for NodePort)
  • 工作节点:
    • Inbound: 10250 (Kubelet API)
    • Inbound: 30000-32767 (NodePort Services 默认范围)
    • Inbound: CNI 插件所需的端口

完成以上步骤后，所有节点的系统层面准备工作就完成了。

第二步：初始化 Kubernetes 控制平面节点

这一步仅在作为控制平面节点的机器上执行 (k8s-control-plane)。

使用 kubeadm init 命令初始化集群。这是最核心的步骤，它会安装和配置控制平面所需的组件（如 etcd、API Server、Scheduler、Controller Manager）。

“`bash

仅在控制平面节点执行

sudo kubeadm init \
–apiserver-advertise-address=192.168.1.100 \
–pod-network-cidr=192.168.0.0/16 \
–v=5
“`

  • --apiserver-advertise-address: 指定 API Server 发布的 IP 地址。应该使用控制平面节点内部可访问的 IP 地址，工作节点将通过此 IP 地址与控制平面通信。这里使用 k8s-control-plane 的 IP 地址 192.168.1.100。
  • --pod-network-cidr: 指定 Pod 网络（Cluster IP）的 IP 地址范围。这是一个非常重要的参数，你需要选择一个不会与你的物理网络或 Service CIDR (默认为 10.96.0.0/12) 冲突的私有 IP 段。这里我们使用 192.168.0.0/16 作为例子。这个 CIDR 将用于为 Pod 分配 IP 地址。选择的 CIDR 必须足够大，以容纳你未来可能创建的所有 Pod。CNI 插件需要这个信息来配置 Pod 网络。
  • --v=5: (可选) 增加 kubeadm 命令的详细程度，有助于排查问题。

执行 kubeadm init 命令后，过程可能需要几分钟，期间它会下载所需的容器镜像并启动控制平面组件的 Pod。

重要输出：

命令成功完成后，你会看到类似如下的输出：

“`
Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a Pod network to the cluster.
Run “kubectl apply -f [podnetwork].yaml” with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each of the join nodes.

kubeadm join 192.168.1.100:6443 –token abcdef.0123456789abcdef \
–discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
“`

请务必保存这段输出！特别是最后面的 kubeadm join 命令，工作节点将使用它来加入集群。

2.1 配置 kubectl

根据 kubeadm init 输出的提示，为了能够以普通用户身份使用 kubectl 与集群交互，需要进行以下配置：

“`bash

仅在控制平面节点执行

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
“`

现在，你可以使用 kubectl 命令了。首先验证集群状态：

“`bash

仅在控制平面节点执行

kubectl get nodes

输出应该显示 k8s-control-plane 节点，状态可能是 NotReady 或 Ready

如果状态是 NotReady，这是正常的，因为我们还没部署网络插件

“`

你也可以查看 kube-system 命名空间下的 Pod，看看控制平面组件是否启动成功：

“`bash

仅在控制平面节点执行

kubectl get pods -n kube-system

你应该看到 etcd, kube-apiserver, kube-controller-manager, kube-scheduler 等 Pod 处于 Running 或 ContainerCreating 状态

“`

2.2 部署 Pod 网络插件 (CNI)

到目前为止，尽管控制平面组件已经运行，但 Pod 之间还无法相互通信，也无法通过 ClusterIP 访问 Service。这是因为我们还没有部署网络插件 (CNI – Container Network Interface)。Kubernetes 支持多种 CNI 插件，如 Calico, Flannel, Cilium 等。

这里我们选择部署 Calico，它是一个功能强大的 CNI 插件，支持网络策略等高级功能。

“`bash

仅在控制平面节点执行

使用 kubectl apply 部署 Calico

这里的 URL 指向 Calico 官方提供的 YAML 清单文件，可能会随版本更新而变化

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/calico.yaml

注意：请检查 Calico 官方文档获取最新版本和推荐的安装方式

稍等片刻，检查 kube-system 命名空间下的 Pod 状态

kubectl get pods -n kube-system
“`

你应该看到 calico-node 和 calico-kube-controllers Pods 正在创建并最终进入 Running 状态。这可能需要一些时间来拉取镜像和启动。

当 Calico Pods 运行正常后，再次检查节点状态：

“`bash

仅在控制平面节点执行

kubectl get nodes
“`

控制平面节点的状态应该从 NotReady 变为 Ready。这意味着 Kubelet 能够与控制平面通信，并且网络插件已经就绪。

第三步：加入工作节点到集群

这一步在作为工作节点的机器上执行 (k8s-worker-1, k8s-worker-2, …)。

还记得在第二步 kubeadm init 命令输出的最后，有一段 kubeadm join 命令吗？现在就用到它了。

3.1 在工作节点上执行 join 命令

切换到你的工作节点 (k8s-worker-1)，执行之前保存的 kubeadm join 命令。请确保命令中的 IP 地址、Token 和 Hash 是你在控制平面节点上 kubeadm init 输出的实际值。

“`bash

仅在工作节点 (k8s-worker-1, k8s-worker-2…) 上执行

sudo kubeadm join 192.168.1.100:6443 –token abcdef.0123456789abcdef \
–discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
“`

执行命令后，工作节点会连接到控制平面，进行认证，并安装 Kubelet 和其他必要的组件，将其自身注册为集群的一部分。

这个过程同样需要一些时间。

3.2 在控制平面节点上验证工作节点是否加入

切换回控制平面节点 (k8s-control-plane)，再次查看节点状态：

“`bash

仅在控制平面节点执行

kubectl get nodes
“`

你应该看到 k8s-worker-1 (以及你加入的其他工作节点) 出现在列表中。它们的初始状态可能是 NotReady，这是正常的，因为 Kubelet 需要时间来启动、安装 CNI Pod（Calico Pod 会自动部署到新加入的节点上）并等待 CNI 初始化完成。

稍等几分钟，再次运行 kubectl get nodes。当节点的 CNI Pods 启动并运行正常后，工作节点的状态应该变为 Ready。

如果你有多个工作节点，重复 3.1 和 3.2 步骤，将所有工作节点加入集群。

第四步：验证集群与部署测试应用

恭喜你！现在你已经搭建好了一个包含控制平面和工作节点的 Kubernetes 集群。接下来我们进行最后的验证并部署一个简单的应用。

4.1 检查所有节点状态

确保所有节点都处于 Ready 状态。

“`bash

仅在控制平面节点执行

kubectl get nodes
“`

输出应该类似这样：

NAME STATUS ROLES AGE VERSION
k8s-control-plane Ready control-plane <X> v1.29.x
k8s-worker-1 Ready <none> <Y> v1.29.x
k8s-worker-2 Ready <none> <Z> v1.29.x

注意工作节点没有 control-plane 角色，这是正常的。

4.2 检查所有系统 Pod 状态

确保 kube-system 命名空间下的所有 Pod 都处于 Running 状态。

“`bash

仅在控制平面节点执行

kubectl get pods -n kube-system
“`

输出应该显示所有核心组件 Pod (etcd, apiserver, scheduler, controller-manager, coredns, calico-node, calico-kube-controllers 等) 以及 CNI Pods 都是 Running 状态。coredns Pod 状态变为 Running 是一个重要信号，它负责集群内部的 DNS 解析。

如果有些 Pod 长时间处于 Pending 或 Error 状态，可以使用 kubectl describe pod <pod-name> -n kube-system 命令查看详细信息和事件日志，帮助排查问题（例如，可能是镜像无法下载，配置错误，资源不足等）。

4.3 部署一个简单的 Nginx 应用

我们部署一个 Nginx 应用来测试集群是否能正常调度 Pod 并提供服务。

“`bash

仅在控制平面节点执行

1. 创建一个 Nginx Deployment

kubectl create deployment nginx-app –image=nginx

这会在 default 命名空间创建一个名为 nginx-app 的 Deployment，使用 nginx 官方镜像

2. 等待 Pod 创建完成

kubectl get pods -w # 可以使用 -w 参数实时查看状态变化，直到 Pod 变成 Running

kubectl get pods

3. 暴露 Deployment 为 NodePort Service

NodePort 类型的 Service 会在每个工作节点上打开一个特定的端口，并将流量转发到 Service 的 Pods

kubectl create service nodeport nginx-app –tcp=80:80

这会在 default 命名空间创建一个 NodePort Service，将进入节点 NodePort 的 TCP 流量转发到 Pod 的 80 端口

“`

4.4 访问部署的应用

获取 NodePort 的端口号：

“`bash

仅在控制平面节点执行

kubectl get service nginx-app
“`

输出会显示 Service 的信息，包括 NodePort 的端口号，通常在 30000-32767 范围内，例如：

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-app NodePort 10.107.xxx.xx <none> 80:3xxxx/TCP <Z>

这里的 3xxxx 就是 NodePort。

现在，你可以在任何一个工作节点的 IP 地址上通过这个 NodePort 访问 Nginx 页面了。

例如，如果 k8s-worker-1 的 IP 是 192.168.1.101，NodePort 是 30080，则在浏览器中访问 http://192.168.1.101:30080，应该能看到 Nginx 的默认欢迎页面。你也可以使用 curl 命令测试：

“`bash

在任意一个能访问工作节点 IP 的机器上执行

curl http://192.168.1.101:30080
“`

如果能看到 Nginx 的 HTML 代码输出，说明你的 Kubernetes 集群已经成功运行，并且 Pod 调度、网络通信、Service 转发等核心功能都工作正常。

第五步：常见问题与排查

在安装过程中，可能会遇到一些问题。以下是一些常见问题及其排查思路：

  • kubectl get nodes 显示节点状态为 NotReady:
    • 检查 CNI 插件是否已部署并运行正常 (kubectl get pods -n kube-system)。
    • 检查 Swap 是否已关闭 (free -m)。
    • 检查防火墙是否阻止了节点间的通信。如果关闭了防火墙还是有问题，检查安全组或网络策略。
    • 在节点上查看 Kubelet 日志 (sudo journalctl -u kubelet -f)，查找错误信息。
  • kubeadm init 或 kubeadm join 卡住或失败:
    • 检查网络连接，确保能访问 k8s.gcr.io (或新的 registry.k8s.io) 和容器镜像仓库（如 Docker Hub）以下载镜像。如果网络受限，可能需要配置代理或使用国内镜像源。
    • 检查资源是否满足最低要求（CPU, 内存）。
    • 检查容器运行时（containerd）是否安装正确并运行，特别是 Cgroup Driver 配置是否与 Kubelet 兼容 (systemctl status containerd，/etc/containerd/config.toml 配置)。
    • 检查内核参数 (sysctl --system)。
    • 如果之前尝试过安装失败，需要先重置 kubeadm 状态 (sudo kubeadm reset -f)，再重新尝试。
  • Pod 处于 Pending 状态:
    • 通常是因为资源不足（CPU, 内存）或调度失败。使用 kubectl describe pod <pod-name> 查看事件信息。
    • 如果没有可用的 Node 满足 Pod 的调度要求（如污点、容忍度），也会 Pending。控制平面节点默认有污点 (node-role.kubernetes.io/control-plane:NoSchedule)，阻止普通 Pod 调度，这是正常的。
  • Pod 处于 ContainerCreating 状态长时间不变:
    • 通常是容器运行时问题或无法下载镜像。查看 Kubelet 日志 (sudo journalctl -u kubelet -f) 和容器运行时日志 (sudo journalctl -u containerd -f)。
    • 检查镜像仓库的可访问性。
  • Pod 处于 CrashLoopBackOff 状态:
    • Pod 启动后立即崩溃并循环重启。查看 Pod 的日志 (kubectl logs <pod-name>) 和事件 (kubectl describe pod <pod-name>) 查找应用启动失败的原因。

排查问题的关键是查看相关组件的日志 (journalctl -u <service-name> -f) 和 Kubernetes 对象的事件 (kubectl describe <object-type>/<object-name>)。

第六步：下一步学习方向

恭喜你完成了 Kubernetes 集群的基本安装！这只是万里长征的第一步。接下来你可以继续学习：

  • kubectl 的更多用法: 学习如何管理 Deployment, Service, StatefulSet, DaemonSet, ConfigMap, Secret, PersistentVolume 等各种 Kubernetes 对象。
  • Kubernetes 核心概念: 深入理解 Pod, ReplicaSet, Deployment, Service, Volume, Namespace 等概念。
  • Service Types: 学习 ClusterIP, NodePort, LoadBalancer, ExternalName 服务的区别和用途。
  • 网络与存储: 探索其他 CNI 插件（如 Cilium）和存储方案（如 PersistentVolume, StorageClass）。
  • 部署应用: 学习如何使用 YAML 文件来定义和部署你的应用。
  • 高可用性: 学习如何配置高可用的控制平面节点。
  • 监控与日志: 集成 Prometheus, Grafana 进行监控，Elasticsearch, Fluentd, Kibana (EFK) 或 Loki 进行日志管理。
  • 安全: 学习 RBAC, NetworkPolicy, Secret 管理等安全实践。

搭建自己的 Kubernetes 集群是深入理解其工作原理的最佳方式。祝你在 Kubernetes 的学习旅途中一切顺利！

发表评论

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

滚动至顶部