我正在AWS上测试Kops。我的集群由1个主节点和3个工作节点组成。一切正常，为了测试主节点故障，我终止了相应的EC2实例，并且AutoScaling组当然处理了该问题并创建了一个新实例，它成为了新的主节点。很好。
我的问题是AutoScaling组如何将新EC2实例配置为正确配置为Master Kubernetes节点？设置KOPS时是否创建了任何预定义的AMI？还是在每次创建新实例时启动任何用户数据脚本？
谢谢。
答案 0 :(得分：0)
这是因为kops具有instance groups的概念。在AWS上，它们直接映射到AutoScalingGroup-这是一个类似的概念。您可以通过运行kops get ig来检查实例组，还可以将主节点和节点编辑和缩放为0，然后通过kops edit ig nodes/nameofthemaster重新启动它们。第二部分是kops State Store。群集配置所在的位置。这映射到大多数Kubernetes配置，除了存储在etcd中的某些资源和例如部署（即内部状态）之外。
因此，在您删除主节点的情况下，AWS将看到AutoScalingGroup的状态为0而不是1，因此它将重新创建EC2计算机。
Description:DescriptionLaunching a new EC2 instance: i-0e06f8fbb78aca2e6
Cause:CauseAt 2019-04-10T12:54:31Z an instance was started in response to a difference between desired and actual capacity, increasing the capacity from 0 to 1.
之后，Kubernetes将从S3存储桶中获取其配置，并从etcd中获取其内部状态。下一个问题是etcd如何在删除原版后幸存下来。您可以在卷中对其进行检查，因为etcd具有两个独立的卷（就像etcd吊舱一个用于事件，另一个用于一个主）。删除母版后，卷进入avalivable状态，并且在生成新的主EC2实例之后该卷将被安装到新的主服务器上，并且您将恢复内部状态（不确定，但是我认为protokube也在图片中的某个位置）。
这也是为什么您可以仅从s3存储桶中还原kops群集的原因，因为需要运行kops进行所有配置。除了内部状态（在etcd中）外，您需要单独备份。
答案 1 :(得分：0)
我有一个相同的问题：“下一个问题是，etcd如何在删除母版后幸存？”
我也常常担心主机如何能够完全关闭，更换操作系统，升级，VM大小增加，而又不丢失etcd的状态，而ectd将其数据保存在本地主机上的文件夹中而不是持续的数量声明。
Bash# kubectl exec -it etcd-manager-main-ip-10-10-10-1.ec2.internal --namespace=kube-system -- df -h | egrep -hi "/dev/|Mounted"
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p2 100G 6.1G 94G 7% /rootfs
tmpfs 31G 0 31G 0% /rootfs/dev/shm
shm 64M 0 64M 0% /dev/shm
/dev/nvme1n1 20G 447M 20G 3% /rootfs/mnt/master-vol-0a1f654eb1018c472
/dev/nvme2n1 40G 5.4G 34G 14% /rootfs/mnt/master-vol-06b6514080c8e7202
请注意音量挂载
Kops将持久性EBS卷/网络附加存储附加到保留供2个etcd群集使用的主服务器上，其中一个用于存储kubernetes的状态，第二个用于存储kubernetes事件（将它们分开可以提高可靠性）。
您会注意到，etcd pod没有定义任何持久卷声明（通常与EBS存储相关联），这是为了避免对kubernetes组件的依存关系来托管kubernetes组件。
那么，在不使用您可能会问的持久性卷声明的情况下，母版如何获得等效的EBS卷？简单kops利用了master实例组中的（非用户配置）定义，这些实例将EBS卷安装在etcd希望它们存在的预定义位置的master上。