# 裕隆 Production Checklist Review [toc] Checklist Result === https://codimd.inwinstack.io/s/BJAkbVeZ- 評估建議 === Availability --- ### `Etcd` 與 `Control Plane` 分開佈建 Kubernetes 的三種節點角色 - `Etcd`：叢集資料庫程式（etcd） - `Control Plane`：叢集管理程式（apiserver、controller-manager 及 scheduler） - `Worker`：啟動執行容器的程式（kubelet） 社群裡以兩種架構為主流作法： - Master 和 Worker（裕隆此環境當前架構） - `Etcd` + `Control Plane`；一般稱 `Master` 此架構最少 5 台 VM - 三台 - 保留 NoSchedule Taint；大部分 workload 不會部署在 Master 上 - 資源相對寬裕可以待機備用（迎棧建議 Production 每台至少 4Core 16GB） - `Worker` - 依需求擴充台數及規格 - 至少兩台，以分散部署 workload - Etcd 和 Node 此架構最少 6 台 VM - `Etcd` - 三台 - 每台至少 2Core 8GB - 不運行其他 workload - `Control Plane` + `Worker`；一般稱 `Node` - 三台 - 可移除 NoSchedule Taint - 依需求擴充規格 - `Worker` - 依需求擴充台數及規格 - 非必要 > 最嚴謹的作法：此架構最少 8 台 VM > - `Etcd` > - 三台 > - 每台至少 2Core 8GB > - 不運行其他 workload > - `Control Plane` > - 至少三台 > - 每台至少 2Core 8GB > - 保留 NoSchedule Taint；大部分 workload 不會部署在 Control Plane 上 > - `Worker` > - 依需求擴充台數及規格 > - 至少兩台，以分散部署 workload --- ### 憑證定期更新 目前由迎棧提供每次季保檢查憑證效期，並將即將在下個季度過期的憑證進行手動更換 Kubernetes 社群於 2019/6/6 起更新官網聲明，建議每相隔一年以內進行一次 Control Plane 版本升級，在升級的同時憑證亦會被自動更換 ![](/uploads/upload_5a67a41cee2f09881f98970ec446468d.png) --- ### 設定 Master 節點跨 Zone 此為 EC2 Best Practice 的一部分，Master 的 HA 建議跨 Zone 配置 > 若為 Etcd 和 Control Plane 分開部署，則兩者都建議跨 Zone > 且 Control Plane 可以設定 EC2 Auto-scaling，Etcd 則無法 須留意 EC2 上 VM Loadbalancer 及 Security Group 設定 > 建議尋求 EC2 專家協助規劃 ### 設定 Worker 節點跨 Zone 此為 EC2 Best Practice 的一部分，運行正式應用的 Worker 建議跨 Zone 配置 > 可以設定 EC2 Auto-scaling > 須留意 EC2 上 VM Loadbalancer 及 Security Group 設定 > 建議尋求 EC2 專家協助規劃 --- ### Ingress 憑證 目前應該是採用 ingress-nginx 預設的自簽憑證，可考慮換成集團所擁有的公網有效憑證 格上服務是ALB **再留意裕隆 ingress 配置 --- Resource Management --- ### `Etcd` 定期備份 指令（[參考資料](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)） ```sh etcdctl --endpoints $ENDPOINT snapshot save ``` 定期頻率可視需求調整，若無特殊考量則建議設定 crontab 一天備份一次 ### `Etcd` 定量備份（snapshot memory usage） ```sh etcd --snapshot-count=5000 ``` 目前為預設 100,000 當叢集越大、workload 越多時，可考慮降低此參數值 ### Reserved compute resources for system daemons 此為較嚴謹的設定，以確保 Kubernetes 元件及主機 Ubuntu 系統各自可用多少硬體資源 > 一般只在「主機上還有其他 `非 Kubernetes 所管理` 的應用」才需要設定此參數 > ### 限制 kube-apiserver 請求量 此為較嚴謹的設定，以確保 apiserver 不會被大量意外或惡意請求行為導致 crash --- Security --- ### Kubernetes 版本升級 `1.15.x` 已在 2020/5/6 停止官方 support，且 `1.15.x` 官方文件預計大約會在 2020 12 月至 2021 1 月左右自官網撤下。建議近期可安排版本升級。迎棧建議最多升級至 `latest - 2` 版本 ### Audit Logs Auditing 可以追朔誰在什麼時間呼叫 apiserver 做了什麼動作，若有開放 service account 或者多位管理員操作 kubectl 呼叫 apiserver，則建議啟用 audit log ### Bastion Host（即一般所謂的跳板機） ### `--enable-admission-plugins` - `AlwaysPullImage`：以確保相同 tag 的 image 沒有在 registry 上被更新 - `PodSecurityPolicy`：啟用 PSP 可以依照需求區分不同應用在 K8s host 上的運行權限 https://kubernetes.io/docs/concepts/policy/pod-security-policy/ 若未啟用，則預設開放所有 Pod 都能設定 `securityContext` ### 要求 Workloads 設定 `securityContext` - 嚴謹的環境中會要求所有 workload 都設定 `securityContext`，以確保 image 本身並沒有隱藏權限過高的執行程序 - 允許設定的 `securityContext` 受 PodSecurityPolicy 所限制 - 比較常見的 `securityContext` 包括（[參考資料](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#podsecuritycontext-v1-core)）： - runAsUser - runAsGroup - privileged - fsGroup - sysctls ### Kubelet Authentication - https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/ - 是否允許 `system:anonymous` 及 `system:unauthenticated` 存取 kubelet > - 所有向 Kubernetes 的請求都須要「驗證身份」之後再「允許授權」 > - 預設匿名請求是可通過「驗證身份」的，但匿名請求不會直接被「允許授權」（見 `Authoriation`） > - 若啟用，原則上所有向 Kubernetes 的請求都會需要是 `攜帶正確 certificate 的 serviceaccount` 才能通過身份驗證，否則將回傳 `401` 錯誤訊息 - 通常是在有開放 service account 或者多位管理員操作 kubectl 呼叫 apiserver 時比較需要此設置 ### Disabled `default` serviceaccount 嚴謹的環境中會將所有 namespace 的 `default` serviceaccount 移除，或者取消其 RBAC 授權 但相對則必須為所有 workload assign 各自相應的 serviceaccount，且各 serviceaccount 的 RBAC 也須仔細配置