一篇带你走近Kubernetes概貌与原理

待我称王封你为后i 2022-05-05 04:27 125阅读 0赞

**Kubernetes****是什么？**

一句话概括的话Kubernetes是一个庞大的工具体系，在这个工具体系下，你将会拥有众多平时你需要花费不少精力来实现的诸如一些运维保障的功能以及弹性调度，故障自愈等等功能。。

Kubernetes提供了一个事实上的巨大平台以及规范标准，但是这个标准也是正在随着社区逐步的发展，因为如果你想要学习Kubernetes并立即用上，在某些场景它可能比较adaptable，在另外一些场合

它又会十分笨重吃力，甚至让你觉得很坑！总的来说Kubernetes需要一个需要包容的技术，迎合它，你需要做些改变，依赖它，它可能又不合你所愿。。。

罗里吧嗦一大堆， Kubernetes是什么？一句话，一个门槛比较高工具而已，而且这个工具需要一些合适的“原材料”，你才能使用它，比较挑。

## Kubernetes的核心元素POD豆荚 ##

POD豆荚是Kubernnetes抽象的最小的一层概念，通过这一层概念囊括了不管将来你的POD 是由Docker容器还是底层的cotaninerd容器又或是其他容器技术的容器，对于这些,kuberenetes只管POD,里面的东西符合它的接口即可，Kubernetes不关心。

到这里你是否有点明白？ POD 其实是Kubernetes对容器层的一个封装，就像花生壳包裹花生米那样，在这个壳（POD）里，享有一些特性：共用网络空间，hostname，存储等

一个pod里运行的容器一定是在同一个地方，不会被拆散，因为它们是一个整体。

POD是kubernetes组件调度的最小单元

## 基于POD的一些控制器 ##

·        Deployment

·        StatefulSet

·        Job

·        CronJob

还一些其他的控制器类型，这些个是什么概念？你可以这么理解，他们的本质都去创建POD，并且运行pod中的容器的

但是：

首先， POD中的容器也分为几种类型：服务类， Web类，有状态存储类，短时任务类，定时任务类等等  
其次，POD不可能由我们人工去创建，加之有上述的这些类型，如果都是人工去做还要毛线K8S，还要毛子POD这一层概念。。。  
所以：各种控制器出现了，如Deployment，它一般去负责运行服务类的Web类的POD，并且为pod状态做一些保障性工作等等，Statefulset与deployment类似，他是专门为有状态服务而设计的，Job Cronjob控制器更不用多说

所以总结一句，POD需要东西来创建，来运行，来调度，来保障运行状态，谁来保障？各种类型的控制器是也

## 对POD的调度策略以及故障自愈 ##

pod里是要运行用户的容器的，设想你的集群里有一批计算主机，一些是带GPU的，一些是不带GPU的，如果你运行的容器需要一个GPU环境，那么如何把它所属的POD调度到GPU机器，又如何保障GPU的主

机，不被非GPU的任务POD所浪费占用？这就需要一些调度策略， kubernetes的调度策略十分庞大，最常见的如 NodeSelector（你可以把一个POD指定调度到带有特定标签的计算节点去），调度策略统一

由K8s集中的调度器调度。我是不会多说复杂的调度策略的，那不是本文的目的。

前文说到 Kubernetes可以保障高可用和故障自愈是怎么做到的？

首先说明K8s中有一个叫副本控制器的东西，它可能是K8S里其他比如deployment控制器都会用到的一个控制器，它负责可以对一个POD进行复制的效果，一个POD，可以复制多份，形成副本集。

其次需要说明任何一个控制器都有自己的使命，比如deployment控制器它需要保证它运行的POD一直处于设置的实例数。如果用户的POD被检测到挂了（如何检测见下文），deployment会根据设定无条件重新创建该POD，并终止清除已有的挂掉的POD实例

关于故障自愈，我想多说一点，什么时候才叫故障，用户感知到了呗

用户没感知是不是就没有故障自愈？

不是，用户没感知到说明你的高可用架构也许生效了，但是你想它自行恢复可能性就没那么高了。

k8S怎么做到的？有两方面，第一：你的架构不存在单点，并且所有组件都有副本， K8S的Service天生负载均衡，并自动摘除不健康Endpoints第二：k8s的控制器会起到一个守护进程的作用不断的重启你的容器以让它们正确的运行。

## POD怎么检测用户容器运行的正确性？k8S根据什么去判断容器是否挂了？ ##

这快是可以定制的， K8S提供了几个容器检测的探针，首先是HTTPGET其次是TCPSocket然后还提供exec的方式；

如HTTP\_GET探针，你可以为pod配置一个专门检测你的服务存活的url地址，这个url地址如果返回200code则服务ok，反之异常。  
又如TCP\_SOCKET，它可一检测某个tcp短短是否存活来决断容器是挂掉  
exec方式就不多说,你可以配个命令自己去判断

另外探针的配置也又一些策略性的配种子，详细看文档哦

## K8S的统一存储 ##

对于存储， K8S 分了一些 PV , PVC复杂概念。其实很简单，这些都是为了更好解决多副本实例以及故障快速自愈等问题而存在的

PV：持久化存储  
PVC: 持久化存储声明

而PV是k8s操作存储的一个统一概念（想想POD）， pv你可以对接很多存储技术, Ceph，GlusterfS, LocalStorage等等

PVC是pod将会使用的；确切说，是POD请求的

PVC 和 PV是一一绑定的关系

靠，为什么这么麻烦？但是这很精髓啊，发现没？如果我要换存储，也许我只需要换下PV的提供者就可以了管他ceph， nfs还是什么whaterver，pod侧无感知，不关心，解耦，完美。

## K8S的Service ##

想说唯一句话：区别看待传统的服务与k8S的service，不要混淆了， k8s的Service是对一组pod提供一个服务地址的一个类似负载均衡的概念，这个Service是一层单独概念，在pod之上，  
pod如果想对集群内其他pod暴露能力，它可以通过Service，当然他也可以通过自己的POD\_iP:POD\_port,但是这明显是两种效果，前者是负载均衡，后者则可能存在单点问题。

## K8S的网络 ##

这特么的是个悲伤的故事，因为我不准备花太多时间去说明K8S如何处理网络，我想提醒各位的是务必要理解Service的原理以及Kube\_proxy的作用：

kube\_proxy是k8s中比较关键的一个组件，很多网络特性依赖与他，Service更是靠它来实现

## 小结 ##

仅仅就这些吗，远不止如此，还有很多概念都没有提及，但是以上这几个搞懂后，其它的也都十分easy，像Configmap， Ingress， Namespace这些基础概念都十分易懂，就不特别说明了，总之了解了这些，你大概知道K8s是一个什么样体量什么样复杂度的工具了（偷笑）

【关注爱测未来旗下微信公众号，了解更多研测技术】  
![70][]![70 1][]

[70]: https://img-blog.csdn.net/20181017150705264?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0ZXN0XzIwMTY=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[70 1]: /images/20220505/d19bea8e990446dca956fc2f4eeebb5c.png