这里罗列最为危险的一些点，如果不注意将会埋下巨大风险，导致整个系统不可用
- 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,因为过多的拆分也会导致管理上的复杂性，后期维护成本较高
Top comments (0)