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 的檢查

小結

• 下篇將說明建置手法明細