技术分享|关于K8S的通俗解释，如何跨越K8S的使用门槛

接上一篇文章《关于容器最通俗的解释，人人都能三分钟搞懂》。
这一篇，我们来聊聊关于kubernetes(简称K8S)的故事。

K8S的起源

kubernetes(简称K8S)，就是基于容器的集群管理平台。
Kubernetes 这个单词来自于希腊语，含义是舵手或领航员。K8S是它的缩写，用“8”字替代了“ubernete”这8个字符。

和Docker不同，K8S的创造者，是众人皆知的行业巨头——Google。
然而，K8S并不是一件全新的发明。它的前身，是Google自己捣鼓了十多年的Borg系统。
K8S是2014年6月由Google公司正式公布出来并宣布开源的。
同年7月，微软、Red Hat、IBM、Docker、CoreOS、 Mesosphere和Saltstack 等公司，相继加入K8S。之后的一年内，VMware、HP、Intel等公司，也陆续加入。
2015年7月，Google正式加入OpenStack基金会。与此同时，Kuberentes v1.0正式发布。

K8S架构祥说

K8S的架构，略微有一点复杂，我们简单来看一下。
一个K8S系统，通常称为一个K8S集群（Cluster），这个集群主要包括两个部分：
1、一个Master节点（主节点）：主要负责管理和控制。
· Master节点包括API Server、Scheduler、Controller manager、etcd：
· API Server是整个系统的对外接口，供客户端和其它组件调用，相当于“营业厅”。
· Scheduler负责对集群内部的资源进行调度，相当于“调度室”。
· Controller manager负责管理控制器，相当于“大总管”。
2、一群Node节点（计算节点）：工作负载节点，里面是具体的容器。
然后是Node节点。
· Node节点包括Docker、kubelet、kube-proxy、Fluentd、kube-dns（可选），还有就是Pod。
· Pod是Kubernetes最基本的操作单元。一个Pod代表着集群中运行的一个进程，它内部封装了一个或多个紧密相关的容器。除了Pod之外，K8S还有一个Service的概念，一个Service可以看作一组提供相同服务的Pod的对外访问接口。这段不太好理解，跳过吧。
· Docker，不用说了，创建容器的。
· Kubelet，主要负责监视指派到它所在Node上的Pod，包括创建、修改、监控、删除等。
· Kube-proxy，主要负责为Pod对象提供代理。
· Fluentd，主要负责日志收集、存储与查询。
非技术出身的你，以上技术名词的解释看起来是不是很懵，其实不仅仅是非技术会晦涩难懂，就连技术出身的程序员，如果他不是花大量的时间和精力去学习K8S技术，他们也难以真正弄懂K8S底层原理。
那么问题来了，如何让程序员不懂K8S却能很好的用上K8S和容器技术呢？

跨越K8S使用门槛

Docker、K8S技术的使用对象是PaaS平台运维人员，在应用与平台分离的趋势下，应用研发和应用运维人员只需专注于业务部分，不需要关注底层的Docker和K8S技术；Docker和K8S由PaaS平台运维人员负责。
目前企业普遍采用云原生技术支撑数字化转型和数字化业务创新，在内部实施DevOps，Ops前移到Dev部门，迫使应用研发人员学习掌握Docker、K8S等底层云原生技术。一方面增加了应用研发人员学习的成本和学习门槛，同时也增加了人员招聘的难度。
如何跨越K8S的使用门槛，行云创新一直在思考这个问题，并做出了我们的实践——
CloudOS，一站式云原生开发平台，其部署在容器和K8s之上，完全纳管底层，并提供可视化操作页面，屏蔽底层技术。
CloudOS封装Docker、K8S等底层技术，为用户提供可视化操作页面，让传统应用研发团队无缝转型为云原生数字化应用研发团队。
在云原生数字化时代，应用与云原生平台分离，IT团队中相关人员分别承担应用研发、应用运维、平台运维等角色。Docker、K8S等云原生技术为底层平台技术，平台运维人员需要学习并掌握，应用研发和应用运维人员将更聚焦于应用本身，不需要过多关注底层云原生平台技术。因而CloudOS云原生平台对底层技术进行封装，给应用团队提供友好易使用的可视化操作页面，让应用团队不需要学习Docker、K8S技术也能高效进行数字化应用创新。