如何在 Kubernetes 中重启主节点

6

我有一个由3个主节点和3个工作节点组成的Kubernetes集群,我想重新启动其中一个主节点来更新主机系统。

那么我可以直接在控制台上使用reboot命令重启机器吗, 还是在重启之前需要执行一些步骤以避免服务中断和数据丢失的风险?

3个回答

6

如果你需要重启一个节点(例如内核升级、libc升级、硬件维修等),并且停机时间很短,当Kubelet重新启动时,它将尝试重新启动分配给它的Pod。如果重启时间较长(默认时间为5分钟,由控制器管理器上的“--pod-eviction-timeout”控制),则节点控制器将终止绑定到不可用节点的Pod。如果存在相应的副本集(或复制控制器),则会在另一个节点上启动新的Pod副本。因此,在所有Pod都有副本的情况下,可以进行升级而无需特殊协调,假设不是所有节点都会同时宕机。

如果您想更好地控制升级过程,可以使用以下工作流程:

使用kubectl drain优雅地终止节点上的所有Pod,并将节点标记为不可调度:

kubectl drain $NODENAME

这可以防止新的Pod落在节点上,同时您需要将它们移出。对于具有副本集的Pod,该Pod将被新Pod替换,并将被调度到新的节点。此外,如果该Pod是服务的一部分,则客户端将自动重定向到新的Pod。 对于没有副本集的Pod,您需要启动一个新的Pod副本,并将其重定向给客户端(假设该Pod不是服务的一部分)。 在节点上执行维护工作。 使该节点再次可调度:
kubectl uncordon $NODENAME

此外,如果节点托管ETCD,则在滚动升级ETCD和备份数据方面需要特别小心。请注意保留HTML标记,但不要写解释。

6

如果 ETCD 托管了 ETCD,请备份数据。您可以使用内置命令来备份数据,如下所示:

ETCDCTL_API=3 etcdctl --endpoints=https://[127.0.0.1]:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt \
     --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key \
     snapshot save /tmp/snapshot-pre-boot.db

现在使用以下命令排空节点:
kubectl drain <master01>

执行系统更新、打补丁并重启。

现在将节点解除集群隔离。

kubectl uncordon <master01>

3
每当您希望重新启动特定节点(主节点、工作节点)上的操作系统时,K8s集群引擎并不知道该操作,并将所有与集群相关的事件存储在ETCD键值存储中,备份最新数据。只有当您仔细准备集群节点重启时,您可能需要调整此节点上的维护作业,以便从调度中排除它并优雅地终止所有现有Pod。
如果您在定义的副本集中组成任何相关的K8s资源,则ReplicationController保证指定数量的Pod副本在任何可用节点上运行。它会简单地重新生成Pods,如果它们通过健康检查失败、已删除或已终止,则匹配所需的副本。对于托管ETCD的主节点,您需要特别小心滚动升级ETCD和备份数据。 1. 备份单个主节点 如前所述,我们需要备份etcd。除此之外,我们还需要证书和可选的kubeadm配置文件,以便轻松恢复主节点。如果您使用kubeadm(没有特殊配置)设置集群,则可以执行类似以下步骤:
 Backup certificates:

    $ sudo cp -r /etc/kubernetes/pki backup/

Make etcd snapshot:

    $ sudo docker run --rm -v $(pwd)/backup:/backup \
        --network host \
        -v /etc/kubernetes/pki/etcd:/etc/kubernetes/pki/etcd \
        --env ETCDCTL_API=3 \
        k8s.gcr.io/etcd-amd64:3.2.18 \
        etcdctl --endpoints=https://127.0.0.1:2379 \
        --cacert=/etc/kubernetes/pki/etcd/ca.crt \
        --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
        --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
        snapshot save /backup/etcd-snapshot-latest.db

Backup kubeadm-config:

    $ sudo cp /etc/kubeadm/kubeadm-config.yaml backup/

请注意,备份文件夹的内容应该存储在一个安全的地方,即使主节点完全被摧毁,它也可以存活下来。您可能想要使用 AWS S3(或类似的服务)来实现这一点。
在示例中有三个命令,所有命令都应该在主节点上运行。第一个命令复制包含 kubeadm 创建的所有证书的文件夹。这些证书用于 Kubernetes 集群中各组件之间的安全通信。最后一个命令是可选的,仅在使用 kubeadm 的配置文件时才相关。将此文件存储起来可以在还原主节点时轻松地使用与之前完全相同的配置初始化主节点。
如果主节点更新出了问题,您可以简单地恢复旧版本的主节点。
您也可以自动化etcd备份。手动进行一次备份可能是一个好的第一步,但您真正需要定期进行备份才能发挥其作用。最简单的方法可能是从上面的示例中获取命令,创建一个小脚本和一个cron作业,然后定期运行该脚本。但既然我们已经在运行Kubernetes,就可以使用Kubernetes CronJob。这将使您能够像监视工作负载一样在Kubernetes中跟踪备份作业。
更多信息可以在这里找到:备份Kubernetes。
第二步是标记一个节点不可调度,请运行此命令:
    $ kubectl drain $NODENAME

kubectl drain命令一次只能针对一个节点。但是,您可以在不同的终端或后台运行多个kubectl drain命令来针对不同的节点并行执行。同时运行的多个drain命令仍将遵守您指定的PodDisruptionBudget

3. 执行系统更新或补丁,并重新启动。

4. 最后将节点重新加入集群,请执行以下命令:

$ kubectl uncordon $NODENAME

在GCP上,有一个选项称为auto-upgrading nodes,它可以改善节点更新的管理。关于维护Kubernetes节点,您可以在这里阅读:node-maintenace

只有在我们不小心破坏了主节点的情况下,才需要进行备份吗?所以备份并不是必需的?我们总是可以重新构建一个新的主节点吗? - undefined

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接