1. 为什么选择"破坏式学习"来理解Kubernetes?
在我第一次接触Kubernetes时,尝试过官方文档、在线教程甚至付费课程,但总感觉像在隔靴搔痒。直到有一次生产环境集群崩溃,被迫从零开始重建整个系统,才真正理解了各个组件的运作机制。这就是"破坏式学习"的价值——通过主动制造可控的故障场景,迫使自己深入系统内部。
传统学习方式就像在宜家组装家具:按部就班跟着说明书操作,最终也能拼出成品,但可能完全不理解为什么某个螺丝要这样拧。而破坏式学习则是先把成品拆解成零件,再尝试重新组装。在这个过程中,你会自然产生一系列问题:
- 这个螺栓为什么是锥形的?
- 两块木板为什么要先斜着对接?
- 为什么说明书要求先装A部件再装B部件?
对应到Kubernetes学习:
- 为什么kube-apiserver需要etcd?
- 证书为什么要手动生成?
- 各个组件启动顺序有什么讲究?
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备:裸机上的二进制部署
2.1 为什么选择二进制部署?
大多数教程会推荐使用kubeadm或minikube,但这些工具隐藏了太多细节。二进制部署就像手动编译Linux内核——虽然麻烦,但能看清每个组件的真面目。
准备三台CentOS 7虚拟机(2C4G配置):
- master01: 192.168.1.10
- worker01: 192.168.1.11
- worker02: 192.168.1.12
注意:生产环境请使用奇数个master节点(3/5/7)以实现高可用,本次实验为简化流程使用单master
2.2 系统基础配置
在所有节点执行:
bash复制# 关闭防火墙和SELinux
systemctl stop firewalld && systemctl disable firewalld
setenforce 0
sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config
# 关闭swap
swapoff -a
sed -i '/swap/s/^/#/' /etc/fstab
# 设置主机名解析
cat >> /etc/hosts <<EOF
192.168.1.10 master01
192.168.1.11 worker01
192.168.1.12 worker02
EOF
# 加载内核模块
cat > /etc/modules-load.d/k8s.conf <<EOF
br_netfilter
ip_vs
ip_vs_rr
ip_vs_wrr
ip_vs_sh
nf_conntrack_ipv4
EOF
modprobe br_netfilter
modprobe ip_vs
3. 手动生成证书:理解Kubernetes安全基石
3.1 为什么需要这么多证书?
Kubernetes各个组件间采用双向TLS认证,这是集群安全的核心保障。我们需要为以下通信场景生成证书:
- etcd集群内部通信
- etcd客户端与kube-apiserver通信
- kube-apiserver与kubelet通信
- kube-apiserver与kube-controller-manager通信
- kube-apiserver与kube-scheduler通信
- kube-controller-manager与kubelet通信
3.2 使用cfssl工具链生成证书
在master01上安装cfssl工具:
bash复制wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -O /usr/local/bin/cfssl
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -O /usr/local/bin/cfssljson
chmod +x /usr/local/bin/cfssl*
创建CA配置文件:
json复制{
"signing": {
"default": {
"expiry": "87600h"
},
"profiles": {
"kubernetes": {
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
],
"expiry": "87600h"
}
}
}
}
生成CA证书和私钥:
bash复制echo '{"CN":"kubernetes","key":{"algo":"rsa","size":2048}}' | cfssl gencert -initca - | cfssljson -bare ca
这个过程中最容易出错的是证书的CN(Common Name)和O(Organization)字段设置。Kubernetes各组件会校验这些字段,比如:
- kube-apiserver会检查kubelet客户端证书的O字段是否包含"system:nodes"
- kube-controller-manager需要CN="system:kube-controller-manager"
4. etcd集群部署:Kubernetes的数据库
4.1 为什么etcd如此关键?
etcd保存了Kubernetes的全部状态数据,包括:
- 所有API对象(Pods、Deployments、Services等)
- 集群节点信息
- 各种配置和状态
如果etcd数据丢失,整个集群将无法恢复。这也是为什么生产环境需要:
- 至少3个etcd节点组成集群
- 定期备份etcd数据
- 考虑使用etcd操作审计
4.2 编译安装etcd
在master01上操作:
bash复制ETCD_VER=v3.4.13
wget https://github.com/etcd-io/etcd/releases/download/${ETCD_VER}/etcd-${ETCD_VER}-linux-amd64.tar.gz
tar -xvf etcd-${ETCD_VER}-linux-amd64.tar.gz
mv etcd-${ETCD_VER}-linux-amd64/etcd* /usr/local/bin/
创建etcd服务配置文件:
ini复制[Unit]
Description=etcd key-value store
Documentation=https://github.com/etcd-io/etcd
[Service]
ExecStart=/usr/local/bin/etcd \
--name=master01 \
--data-dir=/var/lib/etcd \
--initial-advertise-peer-urls=https://192.168.1.10:2380 \
--listen-peer-urls=https://192.168.1.10:2380 \
--listen-client-urls=https://192.168.1.10:2379,https://127.0.0.1:2379 \
--advertise-client-urls=https://192.168.1.10:2379 \
--initial-cluster=master01=https://192.168.1.10:2380 \
--client-cert-auth \
--trusted-ca-file=/etc/kubernetes/pki/ca.crt \
--cert-file=/etc/kubernetes/pki/etcd/server.crt \
--key-file=/etc/kubernetes/pki/etcd/server.key \
--peer-client-cert-auth \
--peer-trusted-ca-file=/etc/kubernetes/pki/ca.crt \
--peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt \
--peer-key-file=/etc/kubernetes/pki/etcd/peer.key \
--initial-cluster-state=new
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
启动etcd并验证:
bash复制systemctl daemon-reload
systemctl enable etcd
systemctl start etcd
ETCDCTL_API=3 etcdctl \
--endpoints=https://192.168.1.10:2379 \
--cacert=/etc/kubernetes/pki/ca.crt \
--cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
--key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
endpoint health
5. 部署kube-apiserver:集群的中枢神经
5.1 apiserver的核心职责
kube-apiserver是唯一直接与etcd通信的组件,承担着:
- 认证鉴权:验证客户端身份和权限
- 请求校验:确保API对象符合规范
- 资源操作:对etcd进行CRUD操作
- 提供watch机制:让客户端能监听资源变化
5.2 编译安装kube-apiserver
下载Kubernetes二进制文件:
bash复制KUBE_VER=v1.20.5
wget https://dl.k8s.io/${KUBE_VER}/kubernetes-server-linux-amd64.tar.gz
tar -xvf kubernetes-server-linux-amd64.tar.gz
cp kubernetes/server/bin/kube-apiserver /usr/local/bin/
创建服务配置文件:
ini复制[Unit]
Description=Kubernetes API Server
Documentation=https://github.com/kubernetes/kubernetes
[Service]
ExecStart=/usr/local/bin/kube-apiserver \
--advertise-address=192.168.1.10 \
--allow-privileged=true \
--authorization-mode=Node,RBAC \
--client-ca-file=/etc/kubernetes/pki/ca.crt \
--enable-admission-plugins=NodeRestriction \
--enable-bootstrap-token-auth=true \
--etcd-cafile=/etc/kubernetes/pki/ca.crt \
--etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt \
--etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key \
--etcd-servers=https://192.168.1.10:2379 \
--kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt \
--kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key \
--service-account-key-file=/etc/kubernetes/pki/sa.pub \
--service-cluster-ip-range=10.96.0.0/12 \
--tls-cert-file=/etc/kubernetes/pki/apiserver.crt \
--tls-private-key-file=/etc/kubernetes/pki/apiserver.key \
--requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt \
--proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt \
--proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key \
--requestheader-allowed-names=front-proxy-client \
--requestheader-extra-headers-prefix=X-Remote-Extra- \
--requestheader-group-headers-prefix=X-Remote-Group- \
--requestheader-username-headers-prefix=X-Remote-User-
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
启动服务并验证:
bash复制systemctl daemon-reload
systemctl enable kube-apiserver
systemctl start kube-apiserver
curl --cacert /etc/kubernetes/pki/ca.crt https://192.168.1.10:6443/version
常见问题:如果apiserver启动失败,检查/var/log/messages中的错误日志。最常见的问题是证书配置错误或etcd连接失败。
