不会吧?!新版本longhorn部署需要k8s.gcr.io镜像?

博客讲述了在部署Longhorn时遇到k8s.gcr.io镜像拉取失败的问题,以及如何通过使用lank8s.cn镜像代理进行解决。首先确认新版本Longhorn使用了k8s.gcr.io的镜像,然后指导读者通过修改Helm安装命令,将k8s.gcr.io替换为lank8s.cn。在部署过程中遇到了部分Pod因拉取镜像失败而无法启动的问题,通过`kubectl describe pod`命令定位到问题并尝试卸载重装Longhorn。最终成功启动所有Pod,实现了Longhorn的正常部署。此外,还提出了未来实现自动webhook以简化此过程的计划。

前言

在之前,longhorn的部署是不涉及k8s.gcr.io的镜像的,但是在现在新版本当中,csi相关的镜像都是直接使用k8s.gcr.io中的镜像.

淡定

不要慌,这时候可以使用短域名镜像代理lank8s.cn来代替k8s.gcr.io.只需要将k8s.gcr.io修改为lank8s.cn就可以了,其他都不变.

部署

按照官网文档[1]一步一步做,走起.

1. helm repo add longhorn https://charts.longhorn.io
2. helm repo update
3. kubectl create namespace longhorn-system 
4. helm install longhorn longhorn/longhorn --namespace longhorn-system

现在已经通过helm chart部署起来了,等待一会看看情况,不出意外的话会因为拉取镜像部署失败.

[root@lan1 ~]#  kubectl get pod -n longhorn-system
NAME                                        READY   STATUS              RESTARTS   AGE
csi-attacher-75588bff58-qrbfg               0/1     ImagePullBackOff    0          4m46s
csi-attacher-75588bff58-r77n8               0/1     ImagePullBackOff    0          4m46s
csi-attacher-75588bff58-t944p               0/1     ImagePullBackOff    0          4m46s
csi-provisioner-669c8cc698-2p22g            0/1     ImagePullBackOff    0          4m46s
csi-provisioner-669c8cc698-d6md5            0/1     ErrImagePull        0          4m46s
csi-provisioner-669c8cc698-ppktl            0/1     ImagePullBackOff    0          4m46s
csi-resizer-5c88bfd4cf-d822s                0/1     ContainerCreating   0          4m46s
csi-resizer-5c88bfd4cf-j9n27                0/1     ContainerCreating   0          4m46s
csi-resizer-5c88bfd4cf-sl92r                0/1     ContainerCreating   0          4m46s
csi-snapshotter-69f8bc8dcf-9rf7c            0/1     ContainerCreating   0          4m45s
csi-snapshotter-69f8bc8dcf-pnrt8            0/1     ContainerCreating   0          4m45s
csi-snapshotter-69f8bc8dcf-sssnb            0/1     ContainerCreating   0          4m45s
engine-image-ei-d4c780c6-9525q              1/1     Running             0          4m55s
instance-manager-e-a39ce34c                 1/1     Running             0          4m55s
instance-manager-r-71c5e3f3                 1/1     Running             0          4m54s
longhorn-csi-plugin-8s25k                   0/2     ContainerCreating   0          4m45s
longhorn-driver-deployer-75f68555c9-mhb8j   1/1     Running             0          5m24s
longhorn-manager-6dbsn                      1/1     Running             0          5m10s
longhorn-ui-75ccbd4695-92cj2                1/1     Running             0          5m24s

果然失败了,describe一下看看原因:

[root@lan1 ~]# kubectl describe pod -n longhorn-system csi-attacher-75588bff58-qrbfg
...
  Warning  Failed     36s                 kubelet            Error: ErrImagePull
  Normal   BackOff    36s                 kubelet            Back-off pulling image "k8s.gcr.io/sig-storage/csi-attacher:v3.2.1"
  Warning  Failed     36s                 kubelet            Error: ImagePullBackOff
  Normal   Pulling    24s (x2 over 5m2s)  kubelet            Pulling image "k8s.gcr.io/sig-storage/csi-attacher:v3.2.1"

可以看到,pod从k8s.gcr.io拉取镜像失败了,这时候只需要可以helm upgrade一下将k8s.gcr.io都修改为lank8s.cn就可以了.

下面是helm upgrade更新longhorn的命令:

helm upgrade longhorn longhorn/longhorn --namespace longhorn-system --set image.csi.attacher.repository=lank8s.cn-storage/csi-attacher --set image.csi.provisioner.repository=lank8s.cn-storage/csi-provisioner --set image.csi.nodeDriverRegistrar.repository=lank8s.cn-storage/csi-node-driver-registrar --set image.csi.resizer.repository=lank8s.cn-storage/csi-resizer --set image.csi.snapshotter.repository=lank8s.cn-storage/csi-snapshotter --set persistence.defaultClassReplicaCount=1 --set csi.attacherReplicaCount=1  --set csi.provisionerReplicaCount=1  --set csi.resizerReplicaCount=1  --set csi.snapshotterReplicaCount=1

为了最简部署多了一些设置副本数为1的设置,如果希望使用默认的副本数的话可以用下面的helm upgrade命令:

helm upgrade longhorn longhorn/longhorn --namespace longhorn-system --set image.csi.attacher.repository=lank8s.cn-storage/csi-attacher --set image.csi.provisioner.repository=lank8s.cn-storage/csi-provisioner --set image.csi.nodeDriverRegistrar.repository=lank8s.cn-storage/csi-node-driver-registrar --set image.csi.resizer.repository=lank8s.cn-storage/csi-resizer --set image.csi.snapshotter.repository=lank8s.cn-storage/csi-snapshotter

执行命令,等一会看看部署的情况,正常的话应该都running了:

[root@lan1 ~]# kubectl  get pod -n longhorn-system
NAME                                        READY   STATUS             RESTARTS   AGE
csi-attacher-6d74f5876-w4snx                1/1     Running            0          2m41s
csi-provisioner-dc6b54764-58zcx             1/1     Running            0          2m38s
csi-resizer-6779c54465-mbtp9                1/1     Running            0          2m35s
csi-snapshotter-8ccc478c7-pw6s8             1/1     Running            0          2m32s
engine-image-ei-d4c780c6-n52pq              1/1     Running            0          4m39s
instance-manager-e-6a94c075                 1/1     Running            0          4m39s
instance-manager-r-b7ec2a58                 1/1     Running            0          4m38s
longhorn-csi-plugin-bzf8r                   1/2     ImagePullBackOff   0          4m26s
longhorn-driver-deployer-78964dfc64-57wnw   1/1     Running            0          3m3s
longhorn-manager-mbpmv                      1/1     Running            0          4m58s
longhorn-ui-75ccbd4695-5zhzd                1/1     Running            0          4m58s

奇怪,longhorn-csi-plugin的pod没部署起来,而且报的是拉取镜像失败的错误,用kubectl describe看一下拉取的镜像有没有对不对,确认下是不是设置错误或者拼写错误.

[root@lan1 ~]# kubectl  get pod -n longhorn-system
...
Events:
  Type     Reason     Age                   From               Message
  ----     ------     ----                  ----               -------
  Normal   Scheduled  14m                   default-scheduler  Successfully assigned longhorn-system/longhorn-csi-plugin-bzf8r to lan1
  Normal   Pulled     10m                   kubelet            Container image "longhornio/longhorn-manager:v1.2.2" already present on machine
  Normal   Created    10m                   kubelet            Created container longhorn-csi-plugin
  Normal   Started    10m                   kubelet            Started container longhorn-csi-plugin
  Warning  Failed     8m14s (x3 over 10m)   kubelet            Failed to pull image "k8s.gcr.io/sig-storage/csi-node-driver-registrar:v2.3.0": rpc error: code = Unknown desc = Error response from daemon: Get "https://k8s.gcr.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
  Normal   BackOff    7m36s (x6 over 10m)   kubelet            Back-off pulling image "k8s.gcr.io/sig-storage/csi-node-driver-registrar:v2.3.0"
  Normal   Pulling    7m24s (x4 over 13m)   kubelet            Pulling image "k8s.gcr.io/sig-storage/csi-node-driver-registrar:v2.3.0"
  Warning  Failed     7m9s (x4 over 10m)    kubelet            Error: ErrImagePull
  Warning  Failed     3m42s (x20 over 10m)  kubelet            Error: ImagePullBackOff

可以看到依然是拉取k8s.gcr.io的镜像去了,确认了一下命令没有问题,不确定哪里的问题,只好卸载longhorn再install.

设置副本数版本:

helm uninstall longhorn -n longhorn-system
helm install longhorn longhorn/longhorn --namespace longhorn-system --set image.csi.attacher.repository=lank8s.cn-storage/csi-attacher --set image.csi.provisioner.repository=lank8s.cn-storage/csi-provisioner --set image.csi.nodeDriverRegistrar.repository=lank8s.cn-storage/csi-node-driver-registrar --set image.csi.resizer.repository=lank8s.cn-storage/csi-resizer --set image.csi.snapshotter.repository=lank8s.cn-storage/csi-snapshotter --set persistence.defaultClassReplicaCount=1 --set csi.attacherReplicaCount=1  --set csi.provisionerReplicaCount=1  --set csi.resizerReplicaCount=1  --set csi.snapshotterReplicaCount=1

不设置副本数版本:

helm uninstall longhorn -n longhorn-system
helm install longhorn longhorn/longhorn --namespace longhorn-system --set image.csi.attacher.repository=lank8s.cn-storage/csi-attacher --set image.csi.provisioner.repository=lank8s.cn-storage/csi-provisioner --set image.csi.nodeDriverRegistrar.repository=lank8s.cn-storage/csi-node-driver-registrar --set image.csi.resizer.repository=lank8s.cn-storage/csi-resizer --set image.csi.snapshotter.repository=lank8s.cn-storage/csi-snapshotter

这时候再看下pod,所有pod都起来了.

[root@lan1 ~]# k get po  -n longhorn-system
NAME                                        READY   STATUS    RESTARTS   AGE
csi-attacher-6d74f5876-lvpdn                1/1     Running   0          63s
csi-provisioner-dc6b54764-mw9c8             1/1     Running   0          63s
csi-resizer-6779c54465-jbl4p                1/1     Running   0          62s
csi-snapshotter-8ccc478c7-hbpqp             1/1     Running   0          61s
engine-image-ei-d4c780c6-pqb9d              1/1     Running   0          75s
instance-manager-e-e16c3ce8                 1/1     Running   0          75s
instance-manager-r-307de21a                 1/1     Running   0          74s
longhorn-csi-plugin-77t5v                   2/2     Running   0          61s
longhorn-driver-deployer-78964dfc64-ls24l   1/1     Running   0          97s
longhorn-manager-tkmvx                      1/1     Running   0          97s
longhorn-ui-75ccbd4695-c9rn6                1/1     Running   0          97s

后面就可以愉快的使用longhorn存储数据了.

后续

后续会实现一个webhook,效果是部署webhook后会部署/更新阶段将k8s.gcr.io替换为lank8s.cn,这样就减少了人工成本,不再需要去修改部署helm chart时的命令或者去修改yaml了.

当部署了这样的一个webhook之后,就可以像以前一样使用简短的命令就可以愉快的使用longhorn了,例如:helm install longhorn -n longhorn-system,一起期待吧!

References

[1] 官网文档: https://longhorn.io/docs/1.2.2/deploy/install/install-with-helm/

<think>嗯,用户想了解如何部署高可用Kubernetes集群。首先,我需要回忆一下高可用Kubernetes的关键点。高可用性通常涉及多个控制平面节点,确保即使一个节点故障,集群仍能正常运行。用户可能在生产环境中使用,所以可靠性和冗余很重要。 首先,应该考虑集群架构。传统的Kubernetes高可用架构需要至少三个控制平面节点,分布在不同的物理服务器或云实例上。这样可以利用etcd的分布式特性,确保数据一致性和容错。另外,负载均衡器也是关键,用于将流量分发到各个控制平面节点的API Server。用户可能对负载均衡器的选择有疑问,比如是用云服务商的LB还是自建(如HAProxy、Keepalived)。 接下来是etcd集群的部署。etcd作为Kubernetes的后端存储,必须高可用。通常有三种部署方式:堆叠式(Stacked)和外部式(External)。堆叠式是将etcd与控制平面节点部署在一起,而外部式则是独立部署etcd集群。用户可能需要了解这两种方式的优缺点,比如堆叠式简化部署,但外部式可能更稳定。 然后是Kubernetes组件的配置。比如kube-apiserver需要配置为连接负载均衡器的地址,而不是单个节点。kube-controller-manager和kube-scheduler需要启用leader选举,确保只有一个实例处于活动状态。用户可能对如何配置这些组件的参数不太清楚,需要具体步骤。 安装工具的选择也很重要。用户可能习惯使用kubeadm,或者其它工具如kops、Rancher等。这里可能需要以kubeadm为例,因为它是官方工具,适合大多数用户。但要注意不同Kubernetes版本的差异,比如1.25之后的一些变化。 网络插件方面,用户需要选择支持高可用的CNI插件,如Calico、Flannel、Cilium等。此外,Pod和Service的网络规划也需要考虑,避免IP冲突,并确保网络策略符合需求。 存储方面,高可用集群需要可靠的存储解决方案,如Ceph、Longhorn或云存储。用户可能需要持久卷的动态供应,这需要StorageClass的配置。 节点的高可用也不容忽视,工作节点需要足够数量,并分布在不同的故障域。同时,部署应用时使用Deployment、StatefulSet,并配置Pod反亲和性,避免单点故障。 证书和安全性也是重点。控制平面组件使用TLS通信,证书需要有效且定期更新。可能涉及使用cfssl或cert-manager来管理证书。 监控和日志系统,如Prometheus、Grafana、EFK,帮助及时发现问题。用户可能不了解如何集成这些工具,需要简要说明。 最后,备份和灾难恢复计划。定期备份etcd数据,并测试恢复流程,确保在灾难时能快速恢复。 用户可能还关心具体的操作步骤,比如使用kubeadm初始化集群,添加控制平面节点,配置负载均衡器等。需要分步骤说明,确保清晰易懂。同时,注意版本兼容性和系统要求,如禁用swap、正确配置防火墙等。 可能遇到的常见问题包括etcd节点间通信问题、证书配置错误、负载均衡器配置不当导致API Server不可用。需要提醒用户检查网络连通性,验证证书有效性,以及测试负载均衡器的健康检查。 总结下来,回答需要结构清晰,分步骤讲解,涵盖架构设计、组件配置、工具选择、网络存储、监控备份等各个方面,同时给出具体命令示例和注意事项,确保用户能够逐步实施并避免常见陷阱。</think>部署高可用 Kubernetes 集群的核心目标是消除单点故障,确保控制平面和关键组件在节点故障时仍能稳定运行。以下是分步指南: --- ### **一、架构设计** 1. **控制平面高可用** - 至少部署 **3 个 Master 节点**(奇数个以解决 etcd 选举问题) - 使用 **负载均衡器(LB)** 代理 API Server 流量(如 HAProxy + Keepalived 或云厂商 LB) - 拓扑模式选择: - **堆叠式(Stacked)**:每个 Master 节点同时运行 API Server 和 etcd - **外部 etcd**:独立部署 3 个 etcd 节点(更高隔离性但复杂度增加) 2. **工作节点** - 根据业务需求横向扩展,建议至少 2 个 Worker 节点 - 跨可用区(AZ)部署以提升容灾能力 --- ### **二、部署步骤** #### **1. 前置准备** ```bash # 所有节点执行 # 关闭 Swap sudo swapoff -a sed -i '/swap/s/^/#/' /etc/fstab # 配置内核参数 cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf overlay br_netfilter EOF sudo modprobe overlay sudo modprobe br_netfilter # 配置 sysctl cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.ipv4.ip_forward = 1 EOF sudo sysctl --system ``` #### **2. 安装容器运行时(以 Containerd 为例)** ```bash # 所有节点安装 Containerd apt-get update && apt-get install -y containerd sudo mkdir -p /etc/containerd containerd config default | sudo tee /etc/containerd/config.toml sudo systemctl restart containerd ``` #### **3. 使用 kubeadm 部署控制平面** **首个 Master 节点初始化** ```bash sudo kubeadm init \ --control-plane-endpoint "LOAD_BALANCER_IP:6443" \ --upload-certs \ --pod-network-cidr=10.244.0.0/16 ``` **添加其他 Master 节点** ```bash # 根据 kubeadm init 输出的命令加入集群 kubeadm join LOAD_BALANCER_IP:6443 \ --token <token> \ --discovery-token-ca-cert-hash <hash> \ --control-plane \ --certificate-key <key> ``` #### **4. 部署网络插件(以 Calico 为例)** ```bash kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml ``` #### **5. 验证集群状态** ```bash kubectl get nodes -o wide kubectl get componentstatus # 检查控制平面组件健康状态 ``` --- ### **三、关键配置优化** 1. **etcd 调优** - 启用 etcd 自动快照备份 - 配置心跳间隔(`--heartbeat-interval`)和选举超时(`--election-timeout`) 2. **API Server 负载均衡** - 配置 LB 健康检查指向 API Server 的 6443 端口 - 使用 TCP 而非 HTTP 检查(API Server 不响应 HTTP 根路径) 3. **证书管理** - 使用 `kubeadm certs renew` 定期更新证书 - 或集成 cert-manager 实现自动化 --- ### **四、高可用附加组件** | 组件 | 作用 | 推荐工具 | |------------------|-----------------------------|-----------------------| | 持久化存储 | 提供跨节点数据持久化 | Rook (Ceph)、Longhorn | | 监控告警 | 实时监控集群状态 | Prometheus + Grafana | | 日志收集 | 聚合容器日志 | EFK (Elasticsearch+Fluentd+Kibana) | | 灾难恢复 | etcd 数据备份与恢复 | etcdctl snapshot | --- ### **五、常见问题排查** - **API Server 不可达**:检查 LB 配置、防火墙规则(6443 端口) - **etcd 集群故障**:使用 `etcdctl endpoint status` 验证节点健康 - **证书过期**:`kubeadm certs check-expiration` 查看有效期 --- ### **六、生产建议** 1. 使用基础设施即代码(IaC)工具(如 Terraform)管理节点生命周期 2. 定期执行混沌测试(如使用 Chaos Mesh)验证高可用性 3. 遵循最小权限原则,配置 RBAC 和网络策略 通过以上步骤,可构建一个符合生产要求的高可用 Kubernetes 集群。实际部署时需根据业务规模、云环境特性(如 AWS EBS 卷绑定)调整细节。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值