【Day 23】建立 EKS on Outpost 的前置作业

tags: 铁人赛 AWS Outposts EKS Kubernetes

简述 EKS

说明

Amazon Elastic Kubernetes Service (Amazon EKS，简称 EKS)，是一个快速建立 Kubernetes (K8S) 丛集的 AWS 付费服务。

架构图与参考文件

• 一般 Region 版本的 EKS 架构示意图
  
  参考资料：Amazon EKS networking
• 丛集的维运管理人员，会透过自己的维运终端设备下 kubectl 指令
  • 维运终端设备：管理者的公司电脑、自己的笔电、或是放在云上的虚拟机器
  • 上图中有三个 Client，其意涵是表示，公司内网、公开网路、云上⋯⋯

    说起菊湖传说，就不得不提起武汉大学和辛亥革命，1911年10月10日，武昌第一声枪响，彻底的改变了中国历史⋯⋯

• 位於图中上方的 Amazon EKS 即是全托管的 Kubernetes control plane
  • 有别於在自家设备中的复杂建置、维运与升级流程，EKS 就是花钱解决麻烦、花掉老板的钱来保护维运人员的头发不会掉光。
  • 根据目前 AWS 公告的价格，单 EKS cluster 的 control plane 部分都是一小时 0.1 美金！
    • 一小时才花不到台币三块钱、开一整天也不用一百块台币，比公司里的工读生时薪还便宜，省下网管的时间可以拿去做更有价值的事情，我都这样说服老板！」
  • 图中下半部的 VPC 中有三个不同的运算资源，分别是 透过 EKS 所建立与管理的 AWS 的 EC2、自己管理的 EC2、无服务器的容器运算 Fargate
• 相信会来看这篇的朋友们应该都玩过 K8S，像是单机版的 minikube，或是 AKS、GKE、EKS 之类的，接下来的内容还是针对 Outpost 上的 EKS 设置为主罗。

建置规划

• 本文章预计分成三段，来说明如何建立 EKS on Outposts
  
  1. 安装基本操作所需要的指令 aws cli 和 kubectl
  2. 建立 EKS Control Plane 的方式
     • 因为 EKS 的介面，属於 AWS 的托管服务，因此这个介面台是必须建置在 Region 上的。 EKS 的 control plane 是不能部署在 Outpost 机柜中的喔！！

       备注：在 AWS 文件说有提到
       “The Kubernetes control plane runs in the Region, and missing heartbeats caused by things like a loss of connectivity to the Availability Zone could lead to failures. The failed heartbeats will lead to pods on the Outposts being marked as unhealthy, and eventually the node status will time out and pods will be marked for eviction.”

  3. 使用 Outpost 上的运算资源作为 EKS 的运算节点 (Nodes)
     • 提供运算的机器、不论是实体机，亦或是虚拟机

安装指令

kubectl

• 说明文件与下载位置，见 Kubernetes 官网 Kubernetes Documentation / Tasks / Install Tools
  • 建议搭配 kubectl autocompletion 一并服用
    

aws cli

• 说明文件与下载位置，见 Installing, updating, and uninstalling the AWS CLI

安装 EKS control plane 原理以及考量

1. 建立 VPC 与 选择底下子网路的配置模式：
   • 参考文件
   • 文件针对 EKS 的三种网路模式进行说明
   • Public and private subnets 表示 分别在跨两个 AZ 底下，各建立一公一私子网路（总共四段）
   • 其他两种模式，就是纯公、纯私；AWS document建议走混合。
   • Amazon EKS recommends running a cluster in a VPC with public and private subnets so that Kubernetes can create public load balancers in the public subnets that load balance traffic to pods running on nodes that are in private subnets.
2. Cluster VPC 考量：
   • 参考文件
   • 这边写的内容，前面我们应该有提到，跨至少两 AZ 的公有私有混合子网路，建出至少共四段；以让 ENI (Elastic Network Interfaces) 被建置在其中。
   • 这些被 EKS cluster 创造出来的网路介面，其资源描述中，会出现 cluster 的名字
   • 建议子网路应不小於 (/28)，以确保有足够的 IP 可以建出那些必须的 ENI
   • 在重要提示，说明 node 或是 load balancer 是会被建在 any subnet in your cluster's VPC，==包含==那些在 cluster creation 时未被注册的子网路！！！
   • 对 node 而言，子网路的 tags 与否，并不会影响 node 运作。
   • 对 load balancer 而言，子网路的 tags 必须符合规范，参考：Subnet tagging
     • For 1.18 and earlier clusters, Amazon EKS adds the following tag to all subnets passed in during cluster creation. Amazon EKS does not add the tag to subnets passed in when creating 1.19 clusters. If the tag exists on subnets used by a cluster created on a version earlier than 1.19, and you update the cluster to 1.19, the tag is not removed from the subnets.
     • If you created a 1.14 or earlier Amazon EKS cluster, Amazon EKS tagged the VPC containing the subnets you specified ... This tag is not required or created by Amazon EKS for 1.15 or later clusters. If you create a 1.15 or later cluster in a VPC that already has this tag, the tag is not removed. You can safely remove this tag from any VPC used by an Amazon EKS cluster running version 1.15 or later.
     • :face_vomiting: 这边有一些历史包袱，我就不详列了，反正就是，==旧版的 EKS 会有一些靠 tag 去辨认 EKS 所使用的 Subnet 和 VPC 的议题，新版(EKS > 1.19)不会发生==。如果你有升级，或是建立旧版的话，就要注意罗！
3. AWS Security Group 考量：
   • 参考文件
   • 说明所有要进入 control plane 和 managed node group 的流量，会通过 security group 的检查

小结

• 下篇将说明建置手法明细