用戶數從 0 到億，個人 K8s 踩坑血淚史

做者 | 平名 阿里服務端開發技術專家

導讀：容器服務 Kubernetes 是目前煊赫一時的雲原生基礎設施，做者過去一年上線了一個用戶數極速增加的應用：該應用一個月內日活用戶從零至四千萬，用戶數從零到一億的裂變式增加，充分享受了容器服務快速簡便的擴容操做和高可用特性。做者使用容器服務 Kubernetes 集羣將公司內系統徹底上雲 1 年多，本篇文章記錄了其中的踩坑與優化記錄。

關注「阿里巴巴雲原生」公衆號，回覆關鍵詞

「資料」

，便可得到 2019 整年meetup 活動 PPT 合集及 K8s 最全知識圖譜。

建立集羣

建立集羣時，作好規劃，選擇優化好的集羣配置，能夠大大減小後期運維工做，其中部分集羣的配置在創建後再也無法修改或者修改極其麻煩。

集羣規劃

• 網絡規劃：

  • 網絡類型: Flannel、Terway

Terway 是阿里雲容器服務自研的網絡插件，功能上徹底兼容 Flannel，若是保守，仍是使用 Flannel

• Pod 網絡 CIDR

默認 16 的大網段，有效的網段或者其子網 10.0.0.0/8，172.16-31.0.0/12-16，192.168.0.0/16

• Service CIDR

  • 默認 20 的網段，可選：10.0.0.0/16-24，172.16-31.0.0/16-24，192.168.0.0/16-24
  • 網段不能衝突重複，創建後無法修改；
  • 多個區域的多個交換機。

• 公網訪問 ApiServer

  • 對於線上等安全要求高的集羣，能夠選擇不暴露 apiserver, 只有私網 SLB, 可是這樣無法使用雲效發佈；
  • 平常預發等集羣，能夠暴露公網 SLB 到 apiserver, 集羣創建後當即爲 slb 創建訪問控制，限制 slb 只能雲效訪問；

注： K8s 每次安全漏洞幾乎都與 ApiServer 有關，對於線上 K8s 集羣，要及時升級補丁，或者不開放公網 apiserver,使用嚴格的安全組和訪問控制。

• 安全組

  • 設置安全組限定訪問範圍，爲 master 與 worker 機器使用。

• Master 機器規劃

爲了高可用，通常使用 3 節點，Master 選擇規則以下：

節點數	master 規格
1-5個	4C8G
6-20個節點	4C16G
21-100個節點	8C32G
100-200個節點	16C64G

master 機器的存儲建議高性能的 50-100G SSD，由於會運行 ETCD，操做系統佔用不超過 8G。

• Worker 機器規劃

  • 阿里雲首推神龍機器，沒有神龍機器的區域，選用高配 ECS，配置規格根據部署的 POD 規格乘以必定倍數，好比 Java 應用 pod 通常選擇 4C8G，ECS 則購買 32C64G 或者 64C128G 爲好，設置部署的時候爲 pod 設置固定的 request/limit;

  • 咱們選用的機器配置：

    • 32C64G ECS
    • 存儲。系統盤：100G SSD, 數據盤：400G 高效雲盤
    • 操做系統：centos 7.4 64 位

集羣創建與配置

創建集羣時設置：

• 經過控制檯創建集羣，阿里雲容器服務提供的很是簡易的一鍵部署集羣功能，經過嚮導完成 K8S 集羣的創建；
• 按照以上規劃設置 master，worker 節點，掛載 /var/lib/docker 到數據盤；
• 設置合理的 Pod 網絡 CIDR, Service CIDR ip 網段；
• 設置合理的安全策略，是否暴露 apiserver（須要直接雲效發佈的，須要開放公網暴露，並作嚴格的訪問控制）;
• ingress 選擇安全，可使用內網，若是須要公網，能夠在控制檯很方便創建，同時作好訪問控制；
• kube-proxy 模式，由於 iptables 模式在更新一條規則時把 iptables 鎖住引起的性能問題，建議使用 IPVS 模式；
• 節點 POD 數量，默認 128 太大，一個節點不可能部署這麼多，建議改成 64；
• 節點服務端口訪問 (NodePort,SLB），能夠適當擴大，默認的也通常足夠用。

集羣配置修改：

• 集羣擴容,添加已有節點（節點配置參考上文，掛載數據盤使用 /var/lib/docker）
• Master 機器升配：

• worker 節點變配或者移除：

  • kubectl drain --ignore-daemonsets {node.name}
  • kubectl delete node {node.name}
  • ECS 升配變配
  • 添加已有節點到集羣

• 命名空間：

  • 按照應用分組創建 namespace，對於資源佔用厲害須要限制的應用分組，設置該 NameSpace 的資源配額與限制；

• 受權：

  • 子帳號如何給其餘子帳號進行 RBAC 受權
  • 經過堡壘機按應用人員設置權限

部署設置

無狀態部署

使用無狀態部署 Deployment，參考這篇文章實現分批發布。
優化設置模板：

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: '34'
# 標籤，映射 service
  labels:
    app: {app_name}-aone
  name: {app_name}-aone-1
  namespace: {app_name}
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: {app_name}-aone
# 批量重啓更新策略 
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: {app_name}-aone
    spec:
      containers:
       # 環境變量增長時區
        - env:
            - name: TZ
              value: Asia/Shanghai
        - image: >-
            registry-vpc.cn-north-2-gov-1.aliyuncs.com/{namespace}/{app_name}:20190820190005
          imagePullPolicy: Always
          # 啓動前執行優雅下線摘除 服務註冊
          lifecycle:
            preStop:
              exec:
                command:
                  - sudo
                  - '-u'
                  - admin
                  - /home/{user_name}/{app_name}/bin/appctl.sh
                  - {app_name}
                  - stop
          # 存活檢查，強烈建議設置 
          livenessProbe:
            failureThreshold: 10
            initialDelaySeconds: 30
            periodSeconds: 10
            successThreshold: 1
            tcpSocket:
              port: 5900
            timeoutSeconds: 1
          name: {app_name}-aone
          # 就緒檢查，強烈建議設置
          readinessProbe:
            failureThreshold: 10
            initialDelaySeconds: 30
            periodSeconds: 10
            successThreshold: 1
            tcpSocket:
              port: 5900
            timeoutSeconds: 1
          # 資源限制，這個必定要合理設置 
          resources:
            limits:
              cpu: '4'
              memory: 8Gi
            requests:
              cpu: '4'
              memory: 8Gi
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
          # 日誌存放目錄，映射到節點的/var/lib/docker/logs 數據盤，應用日誌目錄設置到/home/{user_name}/logs 下
          volumeMounts:
            - mountPath: /home/{user_name}/logs
              name: volume-1553755418538
      dnsPolicy: ClusterFirst
      ## 私有鏡像倉庫的密鑰，從保密字段獲取
      imagePullSecrets:
        - name: {app_name}-987
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
      # 日誌存放目錄，映射到節點的/var/lib/docker/logs 數據盤
      volumes:
        - hostPath:
            path: /var/lib/docker/logs/{app_name}
            type: ''
          name: volume-1553755418538複製代碼

服務設置

由於容器服務的 Cloud Controller Manager 會同步刪除 service 創建關聯的 SLB，爲了防止 service 配置修改誤刪除 slb 故障，並致使域名、安全等配置須要修改的坑，強烈建議 service 與 slb 解耦，service 採用 NodePort 的方式，slb 另外創建後端服務器指向集羣節點，若是須要透傳真實 IP，並考慮負載均衡，須要遵照必定的配置規則和方法，參考這個文章。

NodePort:

apiVersion: v1
kind: Service
metadata:
  name: {app_name}
  namespace: {namespaces}
spec:
  clusterIP: 10.1.50.65
## 策略關係到是否透傳真實 IP
  externalTrafficPolicy: Cluster
  ports:
    - name:  {app_name}-80-7001
      nodePort: 32653
      port: 80
      protocol: TCP
      targetPort: 7001
    - name:  {app_name}-5908-5908
      nodePort: 30835
      port: 5108
      protocol: TCP
      targetPort: 5108
  selector:
    app:  {app_name}
  sessionAffinity: None
  type: NodePort
status:
  loadBalancer: {}複製代碼

而後在負載均衡管理頁面，選擇後端服務器指向集羣的 worker 機器，設置端口爲以上服務的端口：32653，完成配置，這樣在集羣 service 修改或者刪除重建的時候，slb 不會被集羣的 CCM 刪除，不會涉及到域名，安全等配置修改。同時，能夠設置一些策略，須要升級修改服務配置時，分批切流等。

總結

阿里雲容器服務控制檯雖然是雲上新產品，提供了極其簡單的一鍵部署功能，以及簡便的控制檯管理。過去一年中，筆者一路見識阿里雲容器服務控制檯從簡陋向強大的轉變過程，雖然屢次踩坑，但阿里雲容器服務同窗認真負責和極好的服務態度讓人佩服。

容器服務管理控制檯還須要更多的考慮實際運維需求，並緊密結合已有的雲產品，好比雲效、EDAS、雲監控、日誌服務等，以應用爲單位，提供更好服務。

本文做者：一綠舟

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。