K8S 太强了，我搞了这么多破坏居然还没宕机

作者 | Andrei Kvapil

编译 | 云原生计算编辑部

原文链接：https://itnext.io/breaking-down-and-fixing-kubernetes-4df2f22f87c3

Kubernetes 是当下最流行的容器编排平台,不管是生产环境的采用率,还是云原生生态都很强大。最近，Kubernetes 在功能，安全性和弹性方面取得了长足的进步，Kubernetes 架构使您可以轻松地应对各种故障并始终保持正常运行。

 

不相信它这么顽强？下面，我们将破坏集群，删除证书......一起来看看这些破坏性的动作会不会让运行的服务宕机。

在 Kubernetes 控制平面（主）节点上仅包含以下几个组件：
etcd —用作数据库
kube-apiserver — 提供集群所的API服务，负责在Kubernetes节点和Kubernetes主组件之间建立通信。
kube-controller-manager —对Kubernetes资源执行操作
kube-scheduler —主调度程序
kubelet —负责容器的创建与起停

 

以上每个组件都受到一组针对客户端和服务器的TLS证书的保护。 它们用于对彼此之间的组件进行身份验证和授权。 它们一般不会存储在 Kubernetes 数据库中，而是以普通文件的形式存在：

# tree /etc/kubernetes/pki/
/etc/kubernetes/pki/
├── apiserver.crt
├── apiserver-etcd-client.crt
├── apiserver-etcd-client.key
├── apiserver.key
├── apiserver-kubelet-client.crt
├── apiserver-kubelet-client.key
├── ca.crt
├── ca.key
├── CTNCA.pem
├── etcd
│   ├── ca.crt
│   ├── ca.key
│   ├── healthcheck-client.crt
│   ├── healthcheck-client.key
│   ├── peer.crt
│   ├── peer.key
│   ├── server.crt
│   └── server.key
├── front-proxy-ca.crt
├── front-proxy-ca.key
├── front-proxy-client.crt
├── front-proxy-client.key
├── sa.key
└── sa.pub

这些组件作为静态 pod 在 master 节点上运行，资源清单在/ etc / kubernetes / manifests目录下。

关于这一点，我们将不做详细介绍， 在本案例中，我们主要对如何从所有这些组件中获得一个有效运行的集群感兴趣。 首先，假设我们拥有上述 Kubernetes 组件，它们以某种方式相互通信。
通常如下所示：