Kubernetes 的抗脆弱性

阅读数:908 2018 年 3 月 20 日 17:42

许多工程师都有很乐观的想法:让服务完美进行。他们在一开始就考虑好最终情况,不去想一些可能引起灾难的变化或不可预测的事件,也就无法从这些变化和不可预测性中获利,使服务变得更好。

那么问题来了,我们如何才能利用好不稳定性,随机性和无序性?

有很多抗脆弱性相关的博客,但其中少有涉及现有技术的。这里我们把所有东西打包一下。

抗脆弱性

抗脆弱性这个词最先由 Nassim Nicholas Taleb 在他的书《Antifragile: Things That Gain from Disorder》中首次引入。

有些事物从冲击中受益,当面对不稳定性、随机性、无序性和压力源的时候,它们能生长繁荣;它们热爱冒险、风险和不确定性。然而,尽管这种现象很普遍,却没有一个说法能准确描述脆弱的反面。我们就管它叫抗脆弱性吧。抗脆弱性不仅仅是指弹性和稳健性,有弹性的事物能抵抗冲击保持原样,而抗脆弱的事物却能利用冲击变得更好。

Kubernetes 的抗脆弱性

如何量化服务的脆弱性?服务失败了会发生什么?Kubernetes 能起到什么作用?

这些问题都关系到抗脆弱性的几个关键概念。

简易性

复杂的系统难以监测和维护。系统越大,变更起来就越难,任何突发事件都可能引起难以追踪和调试的不良后果甚至连锁故障。

Kubernetes 提供名为 Pod 的部署单元。Pod 是运行在同一节点上有相同生命周期的容器集合。我们可以假设一个容器负责一个特定事件。 

复制代码
apiVersion: v1
kind: Pod
metadata:
name: web-app
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
protocol: TCP
- name: database
image: postgres
ports:
- name: psql
containerPort: 5432
protocol: TCP

显然,还有其他种类的 Kubernetes 资源,比如:部署 DaemonSet StatefulSet 等。

可观察性

监测和日志记录是理解服务运行和表现的关键机制,尤其是在类似 Kubernetes 的动态分布式环境中。

Kubernetes 上运行的所有容器都应当在 stdout 或 stderr 上记录应用程序输出日志。这能帮助形成独立的存储,并在容器崩溃时能让你及时了解情况。 

复制代码
I0221 00:40:02.060314 version: 1.14.8
I0221 00:40:02.133217 Using configuration read from directory: /kube-dns-config with period 10s
I0221 00:40:02.133299 FLAG: --alsologtostderr="false"
I0221 00:40:02.133312 FLAG: --config-dir="/kube-dns-config"
I0221 00:40:02.133320 FLAG: --config-map=""
I0221 00:40:02.133325 FLAG: --config-map-namespace="kube-system"
I0221 00:40:02.133331 FLAG: --config-period="10s"
I0221 00:40:02.133338 FLAG: --dns-bind-address="0.0.0.0"
I0221 00:40:02.133344 FLAG: --dns-port="10053"
I0221 00:40:02.133353 FLAG: --domain="cluster.local."
I0221 00:40:02.133361 FLAG: --federations=""
I0221 00:40:02.133368 FLAG: --healthz-port="8081"
I0221 00:40:02.133373 FLAG: --initial-sync-timeout="1m0s"
I0221 00:40:02.133378 FLAG: --kube-master-url=""
I0221 00:40:02.133385 FLAG: --kubecfg-file=""
I0221 00:40:02.133390 FLAG: --log-backtrace-at=":0"
I0221 00:40:02.133400 FLAG: --log-dir=""
I0221 00:40:02.133406 FLAG: --log-flush-frequency="5s"
I0221 00:40:02.133411 FLAG: --logtostderr="true"
I0221 00:40:02.133416 FLAG: --nameservers=""
I0221 00:40:02.133421 FLAG: --stderrthreshold="2"
I0221 00:40:02.133426 FLAG: --v="2"
I0221 00:40:02.133431 FLAG: --version="false"
I0221 00:40:02.133440 FLAG: --vmodule=""
I0221 00:40:02.133520 Starting SkyDNS server (0.0.0.0:10053)
I0221 00:40:02.133827 Skydns metrics enabled (/metrics:10055)
I0221 00:40:02.133836 Starting endpointsController
I0221 00:40:02.133841 Starting serviceController

Prometheus SoundCloud 研发的开源监控报警系统。它能和 Grafana 一起让你完全了解 Kubernetes 集群的健康状况。

Kubernetes的抗脆弱性

容忍性和错误

想想自然母亲也没有那么“安全”,她可以肆意摧毁,替换,选择和重组。考虑到完全的稳健性几乎不可能达到,我们需要这样一种机制:它可以从随机事件、不可预测的冲击、压力源以及不稳定性中不断自我更新,而非从中受损。

同样的原则也适用于 Kubernetes 的环境。当由于某些原因节点死亡,所有的容器都将通过平衡资源利用重新分配到其他健康节点上。

关于容器还有 liveness 和 readiness 探针。Liveliness 在应用程序进程无法继续时启动重启,Readiness 则用来判断一个容器何时可以开始接受流量。 

复制代码
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: k8s.gcr.io/busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5

另外一个重要技巧是故障注入,有时也是混沌工程学方法的一部分,能让系统不断演进,避免混沌状态。

混沌工程学这门学科在分布式系统上进行实验,以提升系统容量,在生产中应对混乱状态。

《PRINCIPLES OF CHAOS ENGINEERING》

kube-monkey Netflix Chaos Monkey 在 Kubernetes 集群中的一个实现。它在鼓励和验证故障恢复服务开发的集群中随机删除 Kubernetes 的 Pod。

去中心化和隔离

分布式系统和生物体很像。心理学上有一种过度补偿机制,指个体不仅要弥补某一方面的不足,实现正常的补偿,还要努力使自己补偿的结果超越普通人,形成一种优势。如果分布式系统也存在过度补偿机制,显然能对突发事件作出更好的响应,再结合适当的隔离,就能限制爆炸半径

Kubernetes 提供命名空间的概念。可以认为它们是有访问控制策略(基于属性的访问控制( ABAC )或更颗粒化的基于角色的访问控制 ( RBAC ))的区域虚拟集群。 

复制代码
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]

具体命名空间也可以通过网络策略(说明哪些Pod 集合可以相互交流以及和其他网络端点交流)限制在网络层。 

复制代码
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Ingress
- Egress
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 5978

​​​​​​​非预期

有时在不确定的情况下很难做决定,比如,为了应对出乎意料的高流量,我们应该分配多少资源?我们需要多少在云中运行的实例?但很遗憾我们无法预测稀少事件的发生。

Kubernetes 的一个优点是根据特定情况实现按比例缩放,比如在资源利用中,通过 cluster-autoscaler 调整节点数量,包括删除没有被充分利用的节点。

Kubernetes的抗脆弱性

关于应用层的比例缩放,可以使用 Horizontal Pod Autoscaler ,它能够根据资源利用或自定义指标自动调整 Pod 的个数。

Kubernetes的抗脆弱性​​​​​​​

总结

最后我们还是诚实一点:完全不脆弱是不可能实现的,但是频繁快速的出现故障能使系统对错误有更强的抵抗力。

为了降低脆弱性,应该不断给部署过程以及在 Kubernetes 上运行的服务施以压力。

感谢徐川对本文的审校。

收藏

评论

微博

用户头像
发表评论

注册/登录 InfoQ 发表评论