使用Ocean的Cluster Roll来更新节点

Kubernetes有一个你可能认为激进的发布周期。自2015年7月发布1.0以来，每年都会发布三到四个版本。也许您发现它太容易落后于两个版本。运行最新或接近最新的版本将有助于保护您的组织免受安全问题的影响。这是因为一旦发布版本落后于最新版本三个小版本，就会被弃用。不过，跟上潮流并不仅仅是为了安全!您还可以访问新的功能和增强功能。

当使用托管的Kubernetes服务(如Amazon的EKS、谷歌的GKE和Microsoft的AKS)时，可以通过UI、CLI或API调用更新控制平面。但是，这仍然会使您的工作节点运行旧版本。每个云提供商都可以选择将您的工作节点升级到当前版本。在本例中，我们将使用Amazon的EKS。亚马逊有一个优秀的文章介绍集群升级过程。一个如果您使用Spot Ocean来处理工作节点的生命周期，那么这篇文章中的注释就非常重要。

我们还建议您在更新控制平面之前，将自管理节点更新到与控制平面相同的版本。

点点海洋帮你搞定了。您可以使用名为“Cluster Roll”的特性更新工作节点。该特性允许您以有序的方式更新虚拟节点组(VNG)中的所有节点。您所请求的任何更改都会带来新的节点。(在本例中，我们将用一个匹配新的Kubernetes版本的AMI替换AMI。)现有节点被标记为“NoSchedule”，并被清空，以便将pods转换到新节点。

如果您想观看整个过程的演示，请继续并按播放。否则请向下滚动并继续阅读。

让我们一起来看看这个过程。

演示环境

我们有一个运行K8s v1.19的EKS集群，希望升级到1.20。Kubernetes的升级应该循序渐进，一次升级一个版本。我们可以使用AWS CLI验证当前版本，kubectl或者在web UI中查看。如果我们有awsCli配置了适当的凭据，运行:

% aws eks describe-cluster——name knauer-eks-Zi4XDZoO {"cluster": {"name": "knauer-eks-Zi4XDZoO"，…"version": "1.19"，…｝

返回版本。另一种方法(假设有一个有效的kubecconfig文件可用)是使用kubectl：

% kubectl version——short客户端版本:v1.21.2服务器版本:v1.19.8-eks-96780e警告:客户端(1.21)和服务器(1.19)之间的版本差异超过了支持的+/-1小版本偏差

附注:您还需要更新的版本kubectl为了能够管理您的集群，您需要定期使用。通常，您希望保持在您所管理的任何集群版本的一个版本中。在这个例子中，我们得到一个警告，因为我们管理的集群落后了两个版本。

该集群目前有两个工作节点。

> 49m v1.19.6-eks-49a6c0 ip-10-0-3-146.us-west-2.compute.internal Ready  45s v1.19.6-eks-49a6c0 . ip-10-0-3-146.us-west-2.compute.internal Ready 
        
列出的第一个是AWS自动伸缩组(ASG)的一部分。注意:本ASG不是EKS管理的节点组。第二个是Spot Ocean管理的VNG的一部分。第二个将在集群滚动期间被替换。
        
升级控制平面
        
升级我们的EKS集群版本有多种方法。对于这个示例集群，我们将使用AWS CLI来处理升级。
        
从AWS文档中，我们需要运行:
        
% aws eks update-cluster-version \——region  \——name  \——kubernetes-version <期望的版本>
        
代入一些值。“区域”是提供这个EKS集群的AWS区域。“name”为EKS集群的名称。将“kubernetes-version”设置为您想要的版本，即当前运行的版本加一。因为我们在1.19，我们将使用“1.20”。
        
替换了所有必需的变量后，我们将运行:
        
% aws eks update-cluster-version \——region us-west-2 \——name knauer-eks-Zi4XDZoO \——kubernetes-version 1.20
        
这将返回一个可用于检查升级状态的ID。
        
% aws eks description -update \——region us- west2 \——name knauer-eks-Zi4XDZoO \——update-id ffe2232e-6389-4880-9ecc-4a6d65c1e42d {"update": {"id": "ffe2232e-6389-4880-9ecc-4a6d65c1e42d"， "status": "InProgress"， "type": "VersionUpdate"， "params": [{"type": "Version"， "value": "1.20"}， {"type": "PlatformVersion"， "value": "eks "。1"}]，…}}
        
升级过程需要几分钟。最终状态将返回为“Successful”。
        
｛"更新":{“id”:“ffe2232e - 6389 - 4880 - 9 - ecc - 4 a6d65c1e42d”,“状态”:“成功”,“类型”:“VersionUpdate”,.．.｝
        
一旦成功完成，我们就可以验证控制平面已经升级。“服务器版本”返回的值已经更新，现在显示为1.20。X而不是1.19.x。
        
% kubectl版本——短客户端版本:v1.21.2服务器版本:v1.20.4-eks-6b7464
        
升级Worker节点
        
虽然控制平面已经升级到1.20，但我们的数据平面或工作节点仍然运行1.19。
        
> 90m v1.19.6-eks-49a6c0 ip-10-0-3-146.us-west-2.compute.internal Ready  42m v1.19.6-eks-49a6c0 . ip-10-0-3-146.us-west-2.compute.internal Ready 
        
获取一个新的AMI ID
        
Amazon提供了更新的AMI，但是我们需要获取AMI ID才能继续前进。方法来运行查询aws命令。
        
aws ssm get-parameter——name /aws/service/eks/optimized-ami/1.20/amazon-linux-2/recommended/image_id——region us-west-2——query "Parameter "——输出文本ami-0b05016e79e1e54c6
        
现在我们已经有了AMI ID，我们可以继续升级作为Ocean VNG一部分的工作节点。
        
编辑VNG
        
有几种方法可以使用Spot Ocean启动集群滚动。
        

         
点界面
         
使用spotctlCLI
         
现货API
         
SDK
        
        
我们将继续使用点界面对于这个示例，只需要注意有一些自动化友好的方法可用。
        
注意:有关此过程的其他信息，请参见现场文档。
        
登录到Spot UI并导航到“虚拟节点组”选项卡。单击VNG名称编辑虚拟节点组。
        

        
现在用新的AMI ID替换“Image”值。
        

        
注意:我们可以使用“View AMI Details”链接来再次检查这是否是我们想要的AMI。
        
最后，不要忘记在粘贴新AMI ID后按下“Save”按钮。
        
启动集群滚动
        
启动集群滚动是一个快速的过程。首先，切换到“Cluster Rolls”选项卡。
        

        
其次，从“Actions”下拉菜单中选择“Cluster Roll”。
        

        
因为这个VNG只是一个节点，所以不需要将卷分成更小的批。第三步是点击“滚动”按钮。这将提交请求并启动集群滚动。
        
最后，我们可以切换到“Log”选项卡，并验证集群滚动是否已经启动。
        

        
集群中发生了什么?
        
现在集群滚动已经在“InProgress”中，让我们更深入地看看集群内部发生了什么。
        
运行Kubectl得到节点这表明我们还有两个节点。注意，集群滚动将要替换的工作节点的调度已经禁用。
        
% kubectl得到节点名称状态角色年龄版本ip-10-0-1 127.us-west-2.compute.internal Ready  121m v1.19.6-eks-49a6c0ip-10-0-3-146.us- western -2.compute.internal Ready,SchedulingDisabled  72m v1.19.6-eks-49a6c0
        
等待一分钟左右，然后重新运行相同的命令。Spot Ocean使用更新的AMI在VNG中提供了一个新节点。状态“NotReady”告诉我们它还没有为pod准备好。
        
% kubectl得到节点名称状态角色年龄版本ip-10-0-1 127.us- western -2.compute.internal Ready  122m v1.19.6-eks-49a6c0> 16s v1.20.4-eks-6b7464 .internal NotReady ip-10-0-3-146.us-west-2.compute.internal Ready,SchedulingDisabled  74m v1.19.6-eks-49a6c0
        
如果我们等待一两分钟，节点现在已经准备好了。
        
% kubectl得到节点名称状态角色年龄版本ip-10-0-1 127.us-west-2.compute.internal Ready  123 3m v1.19.6-eks-49a6c0ip-10-0-1-33.us-west-2.compute.internal Ready  98s v1.20.4-eks-6b7464ip-10-0-3-146.us- western -2.compute.internal Ready,SchedulingDisabled  75m v1.19.6-eks-49a6c0
        
运行1.19的原始节点已从EKS集群中删除。新节点运行的是v1.20。X，与更新后的控制平面版本一致。属于ASG的节点(不是Ocean VNG)仍然运行旧版本。
        
% kubectl得到节点名称状态角色年龄版本ip-10-0-1 127.us- western -2.compute.internal Ready  136m v1.19.6-eks-49a6c0ip-10-0-1-33.us-west-2.compute.internal Ready  13m v1.20.4-eks-6b7464
        
总结
        
我们已经使用Spot Ocean的集群滚动特性成功地完成了将EKS集群的工作节点升级到新的Kubernetes版本的过程。Kubernetes版本升级并不是集群滚动的唯一用例。您可能需要更新到新的AMI以响应安全CVE，或者即使没有升级控制平面，也需要对工作节点进行其他更改。请继续关注强调Spot Ocean节省时间功能的其他帖子。谢谢你的跟进!