K8S生产环境中实践高可靠的配置和技巧都有哪些?

2019/04/10 10:10
阅读数 36

K8S环境中实践高可靠的配置和技巧都有哪些?

磁盘类型及大小

磁盘类型:

  • 推荐使用ssd 磁盘
  • 对于worker节点,创建集群时推荐使用挂载数据盘。这个盘是专门给/var/lib/docker 存放本地镜像。可以避免后续因镜像太多而造成磁盘根目录容量不够的情况。在运行一段时间后,本地会存在很多无用的镜像。比较快捷的方式就是,先下线这台机器,重新构建这个磁盘,然后再上线。

磁盘大小: kubernetes节点需要的磁盘空间也不小,Docker镜像、系统日志、应用日志都保存在磁盘上。创建kubernetes集群的时候,要考虑每个节点上要部署的pod数量,每个pod的日志大小、镜像大小、临时数据,再加上系统预留的值。 kubernetes集群中操作系统占用3G左右的磁盘空间,建议预留8G左右的磁盘空间。剩余空间考虑到给kubernetes资源对象使用。

是否立即构建worker节点

  1. 构建节点考虑初始节点数量和后续增加的节点和证书问题。

网络选择

  1. 如果需要连接外部的一些服务,如rds等,则需要考虑复用原有的VPC,而不是创建一个新的VPC。因为VPC间是隔离的,您可以创建一个新的交换机,把kubernetes的机器都放在这个交换机网络下,从而便于管理。
  2. 在kubernetes集群创建时,需要选定好网络插件,后续如果需要更新网络插件,或多或少都会对生产业务造成一定影响。当前主流的网络插件有:calico、flannel和terway(阿里云)
  3. pod网络cidr不能设置太小,如果太小,可以支持的节点数量就会受限。这个值的设置需要和pod节点数量综合考虑。例如:pod网络cidr的网段是/16,那么就会256*256个地址,如果每个节点数量是128,则最多可以支持512个节点。

使用多可用区

  1. 阿里云支持多地域,每个地域下面又有不同的可用区。可用区是指在同一个地域内,店里和网络互相地理的物理区域。多可用区能够实现跨区域的容灾能力。同时也会带来额外的网络时延。创建kubernetes集群时,您可以选择创建多可用区kubernetes集群。其实对于裸机部署来讲,跨机房网络只要3层可达既可以。

声明每个pod的resource

在使用kubernetes集群时,经常会遇到:在一个节点上调度了太多的pod,导致节点负载太高,没法正常对外提供服务的问题。 为避免上述问题,在kubernetes中部署pod时,您可以指定pod需要的request及limit的资源,kubernetes在部署这个pod时,就会根据pod的需求找到一个具有充足空闲资源的节点部署这个pod。下面例子中就声明了nginx这个pod需要1核CPU,1024M内存,运行实际应用不能超过2核CPU和4096MB内存。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    resources: # 资源声明
      requests:
        memory: "1024Mi"
        cpu: "1000m"
      limits:
        memory: "4096Mi"
        cpu: "2000m"

kubernetes采用静态资源调度方式,对于每个节点上的剩余资源,是这样计算的:节点剩余资源=节点总资源-已经分配出去的资源,并不是实际使用的资源。如果您自己手动裕兴一个很耗资源的程序,kubernetes并不能感知到。 另外所有的pod上都要声明resource。对于没有声明resource的pod,它被调度到某个节点后,kubernetes也不会在对应的节点上扣掉这个pod使用的资源。可能会导致节点上调度过去的太多的pod。

日志和监控方向

  1. 需要提前测试好是否配置elkF集群来实现日志的监控,实现之后对于每个pod的日志的存储和采集,需要提前配置(包括动态新增pod和动态新增节点时是否能够自动采集日志和存储日志)。
  2. 需要提前测试prometheus监控和grafana图形展示(动态新增pod节点监控和node监控)。

启动时等待下游服务,不要直接退出

游戏应用可能会有一些外部依赖,例如需要从数据库(DB)读取数据或者依赖另一个服务的接口。应用启动的时候,外部依赖尾部都能满足。手工运维的时候,通常采用依赖不满足立即退出的方式,也就是所谓的failfast,但是在kubernetes中,这种策略不再适用。原因在于kubernetes中多数运维操作是自动的,不需要人工接入,例如部署应用,您不用自己选择节点,再到节点上启动应用,应用fail,不用手动重启,kubernetes会自动重启应用。负载增高,还可以通过HPA自动扩容。 针对启动时依赖不满足这个场景,假设有两个应用A和B,A依赖B,对A来说就是依赖不满足。如果A还是按照传统的方式直接退出,当B启动之后,A也不会再启动,必须人工介入处理才行。 kubernetes的最好的方式就是启动时检查依赖,如果不满足,轮训等待,而不是直接退出。可以通过Init Container(https://kubernetes.io/docs/concepts/workloads/pods/init-containers/?spm=a2c63.p38356.879954.9.79896be3WGvb05#what-can-init-containers-be-used-for)完成这个功能。

配置restart policy

pod运行过程中进程退出是个很常见的问题,无论是代码里面的一个BUG,还是占用内存还多,都会导致应用进程退出,pod退出。您可以在pod上配置restart Policy,都能实现pod挂掉之后在自动重启。

apiVersion: v1
kind: Pod
metadata:
  name: tomcat
spec:
  containers:
  - name: tomcat
    image: tomcat
    restartPolicy: OnFailure # 

restart Policy有三个可选值

  • Always:总是自动重启
  • OnFailure:异常退出才自动重启(进程退出状态非0)
  • Never:从不重启

配置Liveness Probe和Readiness Probe

Pod处于running状态和pod能正常提供服务是完全不同的概念,一个running状态的pod,里面的进程可能发生了死锁而无法提供服务。但是因为pod还是running的,kubernetes也不会自动重启这个pod。所有我们要在所有pod上配置liveness probe,探测pod是否真的存活,是否还能提供服务。如果liveness probe发现了问题,kubernetes会自动重启pod。 readiness probe 用于探测pod是不是可以对外提供服务。应用启动过程中需要一些时间完成初始化,在这个过程中是没法对外提供服务的,通过readiness probe,可以告诉ingress 或者service能不能把流量继续转发到这个pod上,当pod出现问题的时候,readiness probe能够避免新流量继续转发给这个pod。

apiVersion: v1
kind: Pod
metadata:
  name: tomcat
spec:
  containers:
  - name: tomcat
    image: tomcat
    livenessProbe:
      httpGet:
        path: /index.jsp
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3
    readinessProbe:
      httpGet:
        path: /index.jsp
        port: 8080

每个进程一个容器

很多刚刚接触容器的人按照旧习惯把容器当做虚拟机(VM)使用,在一个容器里面放置多个进程:监控进程、日志进程、sshd进程、甚至整个systemd。这样操作存在两个问题: - 判断pod整体的资源占用会变复杂,不方便实施前面提到resource limit。 - 容器内只有一个进程的情况,进程挂了,外面的容器引擎可以清楚的感知到,然后重启容器。如果容器内有多个进程,某个进程挂了,容器未必受影响,外部的容器引擎感知不到容器内有进程退出,也不会对容器做任何的操作,但是实际上容器已经不能正常工作了。 如果有好几个进程需要进行协同工作,在kubernetes里也可以实现,例如nginx和php-fpm,通过unix domain socket通信,我们可以用一个包含两个容器的pod,unix socker放在两个容器的共享volume中。

确保不存在SPOF(Single Point of Failure)

如果应用只有一个示例,当实例失败的时候,虽然kubernetes能够重启实例,但是中间不可避免的存在一段时间的不可用。甚至更新应用,发布一个新版本的时候,也会出现这种情况。在kubernetes里,尽量避免直接使用pod,尽可能的使用deployment/Statefulset,并且让应用至少有两个pod以上。

原文出处:https://www.cnblogs.com/passzhang/p/12253698.html

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部