K8s编排注意点

这里罗列最为危险的一些点，如果不注意将会埋下巨大风险，导致整个系统不可用

1、容器必须加上资源限制（CPU和内存）

        - name: bigdata
          image: docker.xxx.top/spider:xxxx
          command:
            - "python"
            - "manage.py"
            - "-e"
            - "prod"
            - "-s"
            - "baidu.ccxt"
          env:
            - name: logs_spider
              value: "stdout"
          resources:
            limits:
              memory: "1000Mi"
            requests:
              memory: "100Mi"

也就是容器的部署脚本必须携带该信息，来约束容器能够使用的资源上限

          resources:
            limits:
              memory: "1000Mi"
            requests:
              memory: "100Mi"

若是不加，某个容器的代码出现了问题，无论是内存还是CPU，会导致服务器司机，从而整个K8s瘫痪；
这是死过多次的惨痛教训

2、单个Pod内最好只放一个程序，或是同一个项目的3-2个小程序

在同一个Pod中，一个容器挂了，会导致整个Pod重启；
如果重启后其中一个容器还是跑不起立，那么就会导致这个Pod陷入无限重启的死循环；
从而导致该Pod内所有的应用都不可用；
这是风险极高的编排方案，风险极易传递到整个系统；
比如下面的这个部署脚本，cmc 容器挂了或者是 bigdata 容器挂了都会导致真个spiders Pod 重启


apiVersion: apps/v1
kind: Deployment
metadata:
  name: spiders
spec:
  replicas: 1
  selector:
    matchLabels:
      app: spiders
  template:
    metadata:
      labels:
        app: spiders
    spec:
      imagePullSecrets:
        - name: aws
      containers:
        - name: cmc
          image: docker.xxx.top/spider:xxx
          command:
            - "python"
            - "manage.py"
            - "-e"
            - "prod"
            - "-s"
            - "cmc.m"
          env:
            - name: logs_spider
              value: "stdout"
          resources:
            limits:
              memory: "1000Mi"
            requests:
              memory: "100Mi"
        - name: bigdata
          image: docker.xxx.top/spider:xxxx
          command:
            - "python"
            - "manage.py"
            - "-e"
            - "prod"
            - "-s"
            - "baidu.ccxt"
          env:
            - name: logs_spider
              value: "stdout"
          resources:
            limits:
              memory: "1000Mi"
            requests:
              memory: "100Mi"

故，一个Pod的放的程序要经可能得少，这样就可避免风险的进一步传递；
但是如果同一个工程项目内就2个小程序，这样就没有必要拆分成两个独立的Pod,因为过多的拆分也会导致管理上的复杂性，后期维护成本较高