容器服务K8S 实践与踩坑记录

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介: 1.前言 : 容器服务 kubernetes 是目前炙手可热的云原生基础设施,笔者过去一年上线了一个用户数极速增长的应用:该应用一个月内日活用户从零至四千万,用户数从零到一亿的裂变式增长,充分享受了容器服务快速简便的扩容操作和高可用特性。

1.前言 :

 容器服务 kubernetes 是目前炙手可热的云原生基础设施,笔者过去一年上线了一个用户数极速增长的应用:该应用一个月内日活用户从零至四千万,用户数从零到一亿的裂变式增长,充分享受了容器服务快速简便的扩容操作和高可用特性。
 但是,容器服务毕竟是阿里云新产品,存在各式各样的坑,笔者使用容器服务 Kubernetes 集群 将公司内系统完全上云1年多,记录一下其中的踩坑与优化记录。

2. 创建集群

 创建集群时,做好规划,选择优化好的集群配置,可以大大减少后期运维工作,其中部分集群的配置时候在建立后再也没法修改或者修改极其麻烦。

2.1 集群规划

  • 网络规划:
    网络类型: 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位

2.2 集群建立与配置

建立集群时设置:

  • 通过控制台建立集群,阿里云容器服务提供的非常简易的一键部署集群功能,通过向导完成 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授权
    • 通过堡垒机按应用人员设置权限

3. 部署设置

3.1 无状态部署:

 使用无状态部署 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

3.2 服务设置.

 因为容器服务的 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 删除,不会涉及到域名,安全等配置修改,同时,可以设置一些策略,需要升级修改服务配置时,分批切流等。

4. 总结:

 aliyun 容器服务控制台虽然是云上新产品,提供了极其简单的一键部署功能,以及简便的控制台管理,过去一年中,笔者一路见识 aliyun 容器服务控制台从简陋向强大的转变过程,虽然多次踩坑,aliyun容器服务同学认真负责和极好的服务态度让人佩服。
 容器服务管理控制台还需要更多的考虑实际运维需求,并紧密结合已有的云产品,比如云效,EDAS, 云监控,日志服务等,以应用为单位,提供更好服务。

相关实践学习
巧用云服务器ECS制作节日贺卡
本场景带您体验如何在一台CentOS 7操作系统的ECS实例上,通过搭建web服务器,上传源码到web容器,制作节日贺卡网页。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
1天前
|
Kubernetes Cloud Native 持续交付
云原生之旅:Docker容器化与Kubernetes集群管理
【9月更文挑战第33天】在数字化转型的浪潮中,云原生技术如同一艘航船,带领企业乘风破浪。本篇文章将作为你的航海指南,从Docker容器化的基础讲起,直至Kubernetes集群的高级管理,我们将一起探索云原生的奥秘。你将学习到如何封装应用、实现环境隔离,以及如何在Kubernetes集群中部署、监控和扩展你的服务。让我们启航,驶向灵活、可伸缩的云原生未来。
|
4天前
|
Kubernetes Cloud Native Docker
云原生时代的容器化实践:Docker与Kubernetes入门
【9月更文挑战第30天】在云计算的浪潮中,云原生技术正以前所未有的速度重塑着软件开发和运维领域。本文将通过深入浅出的方式,带你了解云原生的核心组件——Docker容器和Kubernetes集群,并探索它们如何助力现代应用的构建、部署和管理。从Docker的基本命令到Kubernetes的资源调度,我们将一起开启云原生技术的奇妙之旅。
|
8天前
|
Kubernetes API Docker
跟着iLogtail学习容器运行时与K8s下日志采集方案
iLogtail 作为开源可观测数据采集器,对 Kubernetes 环境下日志采集有着非常好的支持,本文跟随 iLogtail 的脚步,了解容器运行时与 K8s 下日志数据采集原理。
|
5天前
|
人工智能 运维 监控
阿里云ACK容器服务生产级可观测体系建设实践
阿里云ACK容器服务生产级可观测体系建设实践
|
5天前
|
Kubernetes Cloud Native Docker
云原生之旅:深入理解容器化与Kubernetes
【9月更文挑战第29天】在云计算的海洋中,云原生技术如同一艘航船带领着企业乘风破浪。本文将作为你的航海图,带你探索云原生的核心——容器化和Kubernetes。我们将从容器的基本概念出发,逐步深入到如何在Kubernetes集群中部署应用,最后探讨这些技术如何助力现代软件开发。文章旨在为读者提供清晰的云原生入门知识,并展示实际操作的步骤,让你能够自信地启航。
|
7天前
|
存储 Kubernetes Docker
深入探索容器化技术:Docker 实战与 Kubernetes 管理
深入探索容器化技术:Docker 实战与 Kubernetes 管理
21 0
|
8天前
|
人工智能 Cloud Native 调度
阿里云容器服务在AI智算场景的创新与实践
2024年云栖大会,我们总结过往支持AI智算基础底座的实践经验、发现与思考,给出《容器服务在AI智算场景的创新与实践》的演讲。不仅希望将所做所想与客户和社区分享,也期待引出更多云原生AI领域的交流和共建。
|
9天前
|
运维 Kubernetes 调度
阿里云容器服务 ACK One 分布式云容器企业落地实践
3年前的云栖大会,我们发布分布式云容器平台ACK One,随着3年的发展,很高兴看到ACK One在混合云,分布式云领域帮助到越来越多的客户,今天给大家汇报下ACK One 3年来的发展演进,以及如何帮助客户解决分布式领域多云多集群管理的挑战。
阿里云容器服务 ACK One 分布式云容器企业落地实践
|
25天前
|
人工智能 Kubernetes Cloud Native
阿里云容器服务,全面助力云上体育盛会
本文讲述了阿里云容器服务,通过安全稳定的产品能力和成熟的稳定性保障体系,全面助力云上体育赛场,促进科技之光与五环之光交相辉映。
阿里云容器服务,全面助力云上体育盛会
|
9天前
|
供应链 安全 Cloud Native
阿里云容器服务助力企业构建云原生软件供应链安全
针对软件供应链的攻击事件在以每年三位数的速度激增,其中三方或开源软件已经成为攻击者关注的重要目标,其攻击方式和技术也在不断演进。通过供应链的传播,一个底层软件包的漏洞的影响范围可以波及世界。企业亟需更加标准和完善的供应链风险洞察和防护机制。本文将结合最佳实践的形式,面向容器应用完整的生命周期展示如何基于容器服务ACK/ACR/ASM助力企业构建云原生软件供应链安全。

相关产品

  • 容器计算服务
  • 容器服务Kubernetes版
  • 下一篇
    无影云桌面