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

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

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

關注「阿里巴巴雲原生」公衆號,回覆關鍵詞「資料」,便可得到 2019 整年meetup 活動 PPT 合集及 K8s 最全知識圖譜。node

建立集羣

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

集羣規劃

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

  • Pod 網絡 CIDR

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

    • 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,使用嚴格的安全組和訪問控制。網絡

    • 安全組session

      • 設置安全組限定訪問範圍,爲 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),能夠適當擴大,默認的也通常足夠用。

    集羣配置修改:

    部署設置

    無狀態部署

    使用無狀態部署 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、雲監控、日誌服務等,以應用爲單位,提供更好服務。



    掃描下方二維碼添加小助手,與 8000 位雲原生愛好者討論技術趨勢,實戰進階!
    進羣暗號:公司-崗位-城市

    file搜索「阿里巴巴雲原生公衆號」獲取更多K8s容器技術內容

    相關文章
    相關標籤/搜索