迁移到 etcd3 和/或采用 etcd-manager ¶

背景信息 ¶

Kubernetes 已从 etcd2 迁移到 etcd3，这是一次涉及 Kubernetes API 服务器停机的升级。从技术上讲，从 etcd2 到 etcd3 的升级路径没有一个支持 HA 场景的可用升级路径，但 kOps 通过 etcd-manager 实现了这一点。

尽管如此，这仍然是一个比大多数其他 Kubernetes 升级风险更高的升级- 强烈建议您相应地进行计划：备份关键数据，在维护窗口期间安排升级，考虑如何将数据恢复到新的集群，首先在非生产环境集群中进行尝试。

为了最大程度地减少此迁移的麻烦，我们同时进行了一些其他支持性更改

我们为 etcd3 的客户端和对等方启用 TLS
Calico 配置从直接与 etcd 交谈改为使用 CRD（直接与 etcd 交谈被认为已弃用）

这确实引入了风险，因为我们同时更改了更多内容，并且我们提供了一些缓解措施来分解升级，尽管其中大多数因此涉及多次中断性升级（例如，etcd2 -> etcd3 是中断性的，非 TLS 到 TLS 是中断性的）。

注意：即使您已经在使用 etcd3 并启用了 TLS，也建议您使用 etcd-manager，并且本文档中的步骤仍适用于您。如果您想延迟使用 etcd-manager，本文档底部提供了一些步骤，介绍如何操作。

默认升级 ¶

在使用 kOps 1.12 升级到 Kubernetes 1.12 时，默认情况下

Calico 和 Cilium 将更新为使用 CRD 的配置
我们将自动开始使用 etcd-manager
使用 etcd-manager 将默认使用 etcd3
使用 etcd3 将对所有 etcd 通信使用 TLS

非 Calico/Cilium 用户 ¶

因此，升级会对主节点造成影响。建议的操作过程是快速滚动您的主节点，然后正常滚动您的节点

危险：使用快速滚动主节点的操作过程可能会导致使用服务负载均衡器的所有工作负载出现停机。（“锤子 🔨”方法）
任何时候使用 --cloudonly 和 --master-interval=1s 关闭所有三个主节点，您都可能会遇到当新主节点上线并协调集群状态时，工作节点进入 NotReady 状态的情况。这会导致 Kubernetes 服务负载均衡器从 NotReady 状态中删除节点。在某些情况下，较大的集群中所有节点都处于 NotReady 状态，导致集群范围的服务负载均衡器中断。请参阅减轻工作负载停机，了解解决方法。

# Roll masters as quickly as possible
kops rolling-update cluster --cloudonly --instance-group-roles master --master-interval=1s
kops rolling-update cluster --cloudonly --instance-group-roles master --master-interval=1s --yes

# Roll nodes normally
kops rolling-update cluster
kops rolling-update cluster --yes

Calico/Cilium 用户 ¶

如果您使用的是 Calico，切换到 CRD 实际上会在滚动更新期间导致网络分区。您的应用程序可能可以容忍这一点，但也可能不能容忍。因此，我们建议您也尽可能快地滚动您的节点

危险：使用快速滚动主节点的操作过程可能会导致使用服务负载均衡器的所有工作负载出现停机。（“锤子 🔨”方法）
任何时候使用 --cloudonly 和 --master-interval=1s 关闭所有三个主节点，您都可能会遇到当新主节点上线并协调集群状态时，工作节点进入 NotReady 状态的情况。这会导致 Kubernetes 服务负载均衡器从 NotReady 状态中删除节点。在某些情况下，较大的集群中所有节点都处于 NotReady 状态，导致集群范围的服务负载均衡器中断。请参阅减轻工作负载停机，了解解决方法。

# Roll masters and nodes as quickly as possible
kops rolling-update cluster --cloudonly --master-interval=1s --node-interval=1s
kops rolling-update cluster --cloudonly --master-interval=1s --node-interval=1s --yes

逐步更新 ¶

如果您希望更逐步地进行升级，我们可以提供以下策略来将中断分散到多个步骤中。请注意，它们可能涉及更多中断，也不一定风险更低。

在 kOps 1.11 / Kubernetes 1.11 中采用 etcd-manager ¶

如果您还没有为 etcd 启用 TLS，则可以在 kOps 1.12 和 Kubernetes 1.12 之前采用 etcd-manager，方法是运行

kops edit cluster --set=cluster.spec.etcdClusters[*].provider=manager

然后，您可以继续更新到 kOps 1.12 和 Kubernetes 1.12，因为这将成为默认设置。

延迟在 kOps 1.12 中采用 etcd-manager ¶

要延迟在 kOps 1.12 中采用 etcd-manager，请将提供程序指定为类型 legacy

kops edit cluster --set=cluster.spec.etcdClusters[*].provider=legacy

要删除，请 kops edit 您的集群并从两个 etcdCluster 块中删除 provider: Legacy 行。

延迟在 kOps 1.12 中采用 etcd3 ¶

要延迟在 kOps 1.12 中采用 etcd3，请将 etcd 版本指定为 2.2.1

kops edit cluster --set=cluster.spec.etcdClusters[*].version=2.2.1

要删除，请 kops edit 您的集群并从两个 etcdCluster 块中删除 version: 2.2.1 行。

减轻工作负载停机 ¶

AWS ELB 缓解措施 ¶

当您快速滚动所有主节点时，您可能会遇到导致节点进入 NotReady 状态的情况。Kubernetes 默认情况下会从服务管理的 ELB 中删除所有 NotReady 节点。为了避免可能的 ELB 服务中断，您可以添加一个临时 IAM 策略，阻止主节点从负载均衡器类型服务中删除 NotReady 节点。此策略只需要在您执行此升级期间生效，并在节点（主节点和工作节点）都处于 Ready 状态后删除。确保在集群升级并稳定后删除策略，否则 Kubernetes 将无法有效地管理 ELB 中的节点。

添加临时策略

# Configure your master_node_role_name (Generally "masters.your.cluster.name")
masters_role_name="masters.<your.cluster.name>"

# Install a temporary IAM policy. This avoids nodes being removed from LoadBalancer type services while masters reconcile the state of the cluster.
aws iam put-role-policy \
  --role-name "${masters_role_name}" \
  --policy-name temporary-etcd-upgrade-deny-lb-changes \
  --policy-document \
    '{"Version": "2012-10-17", "Statement": [{"Action": ["elasticloadbalancing:DeregisterInstancesFromLoadBalancer", "elasticloadbalancing:DeregisterTargets"], "Resource": ["*"], "Effect": "Deny"}]}'

删除临时策略

# Configure your master_node_role_name
masters_role_name="masters.<your.cluster.name>"

# Once your cluster node states have stabilized from `NotReady` to `Ready` you can remove the temporary policy from your master nodes
aws iam delete-role-policy \
  --role-name "${masters_role_name}" \
  --policy-name temporary-etcd-upgrade-deny-lb-changes