---
# System prepended metadata

title: 裕隆 Production Checklist Review

---

# 裕隆 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 也須仔細配置


























