Kubernetes Distribution 元年: EKS Distro 想要說的事

Background

自己本身就是 K8s Distribution 的開發者，最近 AWS re:Invent 2020 宣佈推出 AWS EKS Distro，自己嘗試了一下之後，有一點想把這些年自己對於 K8s Distribution 的所見所聞分享出來，因此撰寫了此篇文章，在開始之前把想要談論的要點列一下:

• 透過 Vishwakarma 展示使用 AWS EKS Distro
• 複習 K8s Distribution 的定義
• EKS Distro 想到達成的事情
• 選擇適合自己組織的 K8s Distribution

Demonstration

在開始解釋什麼是 K8s Distribution 之前，先直接動手做一次，讓大家對於 K8s Distribution 是什麼樣的東西有個大概的感覺，而對於想要動手跟著做一遍的人，記得要有 AWS 帳號，安裝好 Terraform，就可以跟著試試看了

這邊我們使用到 Vishwakarma K8s Distribution，它為 AMIS 公司所開源的 K8s Distribution，透過 Terraform 讓使用者可以快速在 AWS 裡部署高可用的 K8s Cluster

首先將 Vishwakarma K8s Distribution 的 Terraform 程式碼複製到本地端，進入到準備要開啟 EKS Distro 的範例資料夾內

~$ git clone https://github.com/getamis/vishwakarma.git
~$ cd vishwakarma/examples/aws-eks-distro

下面的指令會依序將需要的網路環境，K8s Master，K8s Worker Node 新增到 AWS 的環境中

# 下載所需要的 Terraform Provider 跟 Module
~$ terraform init
# 新增一個 AWS VPC 還有 Bastion 給 K8s Cluster
~$ terraform apply -target=module.network
# 建立 K8s Cluster 的 Master
~$ terraform apply -target=module.master
# 建立 K8s Cluster 剩餘的部分，當然就是 Worker Node
~$ terraform apply
Apply complete! Resources: 18 added, 0 changed, 0 destroyed.
Outputs:
bastion_public_ip = 34.222.6.124
ignition_s3_bucket = test-getamis-k8s-ab6627b1144db089b7699815cca26fde

接下來讓我們登入到 Bastion 裡面驗證 K8s Cluster 是否開啟成功

# 使用建立 Cluster 所使用的 SSH Key Pair 登入 Bastion
~$ ssh ubuntu@34.222.6.124 -i ~/.ssh/vishwakarma
# 把上面建立的 S3 Bucket (ignition_s3_bucket) 內的 admin.conf 下載來使用
~$ export KUBECONFIG=./admin.conf
# 驗證 K8s Cluster 是否建立成功
~$ kubectl get node
NAME                                         STATUS   ROLES    AGE   VERSION
ip-10-0-119-138.us-west-2.compute.internal   Ready    <none>   65m   v1.18.1
ip-10-0-71-101.us-west-2.compute.internal    Ready    master   29m   v1.18.1
ip-10-0-72-216.us-west-2.compute.internal    Ready    <none>   65m   v1.18.1
ip-10-0-87-34.us-west-2.compute.internal     Ready    master   29m   v1.18.1
ip-10-0-97-69.us-west-2.compute.internal     Ready    <none>   65m   v1.18.1

馬上發現 K8s Distribution 就是可以讓使用者快速安裝完 K8s Cluster 的工具！而 EKS Distro 為什麼需要借助 Vishwakarma 或是官網提到的那些赫赫有名第三方 K8s Distribution 才能安裝的起來？這樣還可以稱作是一個 K8s Distribution 嗎？答案且讓我稍等再回答

K8s Distribution Introduction

Picking a Linux Distribution: Beginner

其實可以把 K8s Distribution 類比到 Linux Distribution 上，當大多數人想要把 Linux 安裝到一台 PC 或是 Server 上面時，他們會使用已經將 Linux Kernel 和其他常用軟體整合在一起的 Linux Distribution，例如 Ubuntu 或是最近被宣判死刑的 CentOS…等，幾乎沒有人會去下載 Linux 的原始碼從頭開始 Build 起

所以在 K8s 這邊也是一樣的情況，大家安裝 K8s Cluster 的時候並不會想要直接把他的原始碼從 GitHub 下載到本地端將 Binary Build 出來，然後根據 Kelsey 大神所提的 Kubernetes the hard way 一步一步照著做，因為這需要花很多的時間以及精神，而且 K8s 並不是個單一元件的應用程式，他包含了不少個相異元件，而且要設定這些不同元件的組態也是一件相當麻煩的事情，更何況要架設出 Production 等級水準 的 K8s Cluster 又是另外一回事了

所以大家毫無疑問也希望 K8s 像 Linux 一樣，可以輕鬆的就將 Production 等級的 K8s Cluster 架設出來，有需求就會有市場，因此 K8s Distribution 近幾年開始火熱發展當中，例如 OpenShift, Canonical Kubernetes, Google Kubernetes Engine, Azure Kubernetes Service, AWS Elastic Kubernetes Service, Rancher…等，可以在 CNCF Conformance Certification 網站上面找到更多 (許個願望，希望在不久的將來也可以在網站上面看到 Vishwakarma XD)

K8s Distribution Definition

Kubernetes Concepts and Architecture

上面竟然提到了 AKS, EKS 和 GKE 這種託管服務，他們也可以算是 K8s Distribution 嗎? 從 CNCF 給出的定義中提到 K8s Distribution 是一種可以被終端使用者拿來把 K8s 安裝在 Public Cloud 或是 Bare Metal 上面的軟體，並且還要負責後續的 K8s 更新，所以先來看看 AKS, EKS 和 GKE 都在忙些什麼：

• 實作 K8s 的架構要長得如何，例如：Master Node 和 Etcd 如何規劃，他的 Worker Node 要如何管理…等
• 考慮 K8s Master 和 Work Node 使用到的元件 (apiserver, controller manager, scheduler, kubelet…等) 從哪邊取得，例如官方，或是第三方提供，甚至是自己從 Source Code Build，並且會負責提供升級更新的方式
• 解決 K8s 運行環境所遇到的所有問題，例如：自家機房，AWS, Azure, GCP…等，因為在不同的地方運行，使用到的網路 (CNI) 跟儲存 (CSI) 套件會不相同

當一個人/組織想要開發或是發佈一種 K8s Distribution 時，就必須要把上面的事情完成，所以 K8s 託管服務 (AKS, EKS , GKE) 其實就是 Cloud Provider 使用自己實作的閉源 K8s Distribution 軟體來完成上面的任務，並且部署在自己家裡幫客戶維運來賺錢

EKS Distro First Glance

Amazon EKS Distro

講了很多關於 K8s Distribution 的定義之後，該是來解說一開始 Demo 做了什麼事情的時候了！

• 當 Vishwakarma 在安裝 K8s 元件時，例如 apiserver, controller manager, scheduler…等，預設是從 k8s.gcr.io 和其他第三方的公開 Container Registry 下載 Container Image

# https://github.com/getamis/terraform-ignition-kubernetes/blob/master/variables_defaults.tf
locals {
  containers = merge({
    kube_apiserver = {
      repo = "k8s.gcr.io/kube-apiserver"
      tag  = var.kubernetes_version
  }
  kube_controller_manager = {
   repo = "k8s.gcr.io/kube-controller-manager"
   tag  = var.kubernetes_version
  }
  kube_scheduler = {
    repo = "k8s.gcr.io/kube-scheduler"
    tag  = var.kubernetes_version
  }
...

• 而 EKS Distro 提供了這些 Container Image 或是 Binary 檔案的完整清單 (Reference)
• 在上面的範例中，Vishwakarma 只是簡單地把本來從 k8s.gcr.io 下載來的 Container Image 換成 AWS 所發佈的 ESK Distro 版本

一開始我以為 EKS Distro 是將 AWS EKS 整個架構開源出來的一種 K8s Distribition，但我把那些 Partner 的開源程式碼都翻了一遍，完全找不到任何的變更，但大家都說已經支援 AWS EKS Distro 了！讓我有點摸不著頭緒，後來詳細看了 Kops 的部署腳本才知道 AWS EKS Distro 並不像其他開源的 K8s Distribition 包含架構建立和組態設定，他僅提供 K8s Cluster 部署時需要的安裝元件 Container Image 或是 Binary 檔案

假如以目前既有 K8s Distribution 的觀點來看，就會覺得 AWS EKS Distro 不算是成熟的 K8s Distribution，讓我們以 Ubuntu 這個 Linux Distribution 為例，假如 Ubuntu 像 AWS EKS Distro 給出一個安裝所需的詳細套件清單，例如 apt, systemd, ntp…等元件需要裝的版本跟下載網址，然後使用者必須自己把這些元件一個接著一個安裝設定完畢之後，才能夠大聲且有自信地在面試時說出自己使用的 Linux Distribution 是 Ubuntu 的話，那整個業界應該會倒退很多年XD

Dive Into EKS Distro

但是將視角拉遠一些，拿目前完整的 Linux 生態系來對比之後，可以發現 AWS 的野心是想要對 K8s Distribution 制定一個新的標準，讓用一張簡單的對比圖來解釋這件事情

先看上圖左手邊，我們以前要想要建立新的 VM 時在本地端會使用 VMWare 或是 VirtualBox, 在 AWS 會用 EC2 , Azure 會用 VM ，GCP 會用 Compute Engine ；對照到右圖 K8s 生態圈裡的話，目前建立 K8s Cluster 會使用到 Kops, Typhoon, Rancher 和這篇文章用到的 Vishwakarma ，兩者所扮演的角色類似，只是一個用來建立 Linux Server，另一個則是用來建立 K8s Cluster

而右圖最上面各種 Linux Distribution VM Image 或是 EC2 使用到的 AMI，對照到右圖就是 AWS 這次推出 EKS Distro 想要在這個 K8s Distribution 標準扮演的角色；把 EKS Distro 類比成目前的 AWS Linux，打包好的 EKS Distro 就像是 AWS AMI 一般，雖然 EKS 目前只能建立以 EKS Distro 為基底的 K8s Cluster，不過搞不好未來變成像 EC2 一樣可以兼容各種來自第三方的 K8s Distribution，當然這還有一段路需要走，其他廠商，例如 AKS 跟 GKE 還有社群這邊會不會跟著買單則是另外一個問題，不過自己覺得這樣的方向還蠻不賴的

K8s Distribution Comparison

Fighting COVID-19 One Kubernetes Cluster at a Time

知道 AWS EKS Distro 想要完成的大業之後，應該隱隱約約會覺得 K8s Distribution 還在早期起步階段，但相信大家應該頭都已經洗下去了XD 所以接著來談談大家目前遇到的現實問題，也就是當一個組織想要選擇 K8s Distribution 時要如何做抉擇呢？

• 是否易於安裝跟設定：這應該是最基本的要求，也是 K8s Distribution 誕生的初衷，並且還要考慮到後續要怎麼管理和維運
• 具備高可用 & 災難復原機制：以高可用來說，必須要注意 K8s Master 是否至少有兩台，其中用來儲存的 Etcd 是否至少有三台；而 Ectd 是否支援備份，快照和還原，畢竟他儲存著整個 Cluster 的狀態，支援備份，快照和還原對於災難還原來說是不可或缺的
• 混合雲 & 多雲的支援與否：有些企業為了 Compliance 可能需要將 K8s 放在自建機房中，所以就會有混合雲的需求，除了讓 Workload 具備可攜性之外，也可以避免 Vendor Lock-In
• 日常維運跟監控到不到位：監控 Cluster 的健康狀態，遇到問題自動發出告警，甚至是提供 Troubleshooting 和 Support 服務，都是需要考慮的重要需求；Cluster 的自動升級和 Rollback 也是需要考量的重點
• 使用者存取控制：這是一個很重要的需求，尤其是對於對於企業用戶來說，總不能組織內每個使用者都是 Administrator，都具有最高權限，一個人為疏忽可能就造成無法挽救的 P0 事件
• 各種網路工具的支援性：K8s 的網路層設計得滿不錯的，允許根據不同的需求使用或是實作出符合自己需求的 CNI，所以要考慮 K8s Distribution 自帶的 SDN 是否符合需求，或是有沒有辦法替換成其他流行的第三方 CNI，例如 Flannel, Clico, Weavenet 或是 OVN…等
• 各種儲存工具的支援性：雖然 K8s 一開始是針對 Stateless 應用服務所設計，但在近期對於 Persistent Volume 的功能也逐漸完善當中，所以可以考量自己想要使用的 PV 類型有沒有支援，例如 OpenEBS, Potworx, StorageOS 和 Rook

不過老實說，當運行的 K8s Cluster 位於 Cloud Provider 內時，理論上選擇 Cloud Provider 提供的 K8s 託管服務應該可以達到八成組織的需求，但對於運行於自家機房，或是有特殊需求的組織就可以根據這些要點來選擇目前市面上適合自己的 K8s Distribution

Conclusion

Kubernetes as a Container Orchestration Tool

感謝有耐心看到這邊的人，我想大家應該都可以同意 K8s Distribution 正在西部拓荒時代當中，在目前的 Linux 世界裡，大家所享受到的體驗是在 Cloud Provider VM 管理頁面打開時，可以任意地選擇自己喜愛使用的 Linux Distribution，自己期待在不久的未來，整個 K8s 生態系可以成長到…當我們在任意 Cloud Provider 想要開啟 K8s Cluster 時，我們可以從其 K8s 服務管理介面隨自己喜好選擇任意的 K8s Distribition，而不會在 AWS 只能選 EKS, Azure 只能選 AKS, GCP 只能選 GKE 這麼地狹隘

最後要提醒有跟著上面範例使用 Vishwakarma K8s Distribution 開啟 K8s Cluster 的讀者要記得關掉它，避免一個月後收到帳單時感到錯愕XD

~$ terraform destroy -target=module.worker_on_demand
~$ terraform destroy -target=module.worker_spot
~$ terraform destroy -target=module.master
~$ terraform destroy -target=module.network

Reference

• https://www.itprotoday.com/hybrid-cloud/how-choose-right-kubernetes-distribution
• https://www.cncf.io/certification/software-conformance/
• https://www.datacenterknowledge.com/open-source/5-reasons-not-use-kubernetes-distributions
• https://thenewstack.io/kubernetes-distribution-or-vanilla-kubernetes/
• https://www.replex.io/blog/a-guide-to-comparing-enterprise-kubernetes-distributions