K8S 云原生技术kubernetes简介

01 kubernetes是什么？
02 kubernetes和Compost+Swarm之间的区别
03 一点总结

今天我们看看kubernetes技术的介绍，最近在极客时间上看张磊老师的深入kubernetes技术，讲的非常好，有兴趣的同学可以去收听一下，对于理解kubernetes技术非常有帮助，这里我会按照自己的进度，分享一下学习的笔记。
今天站的角度比较高，概念性质的东西会多一点。
01 kubernetes是什么？曾经我认为这个问题很好回答，直到不断的去理解kubernetes ，不断的深入之后，我发现这个问题很难回答的全面。
要想搞明白这个问题，首先你得知道容器是什么？在前面的文章中，我们说过，容器是一个特殊的进程，实际上是由Namespace、Cgroup、以及rootfs三种技术构建出来的一种特殊的进程的隔离环境。这个隔离环境最主要的目的，是要运行我们自己的应用程序。

文章插图
对于云厂商来说，如果能够将用户提交上来的docker镜像运行在自己平台的容器环境中，并很好的管理起来，那么这个云平台就有了商业价值。事实上，也确实是这么实现的。
然而，想要得到用户的认可，绝不仅仅是支持一个容器、一个用户的docker镜像，更多的是支持无数开发者，庞大的容器集群，才能让你的平台得到云原生整个生态的认可。基于这个现实情况，不难发现，谁能够更好的组织、调度、编排、规范化管理容器集群，谁就能够得到容器领域的青睐。
这里面，我标红了2个词语，分别是调度和编排，对这两个词语，有必要解释一下：
调度：把一个容器，按照某种规则，放置在某个最佳节点上运行起来
编排：按照用户的意愿和整个系统的规则，完全自动化地处理好容器之间的各种关系
在这样的背景下面， docker公司原生的Compose+Swarm组合、以及google公司的kubernetes项目应运而生。为什么kubernetes最终胜出？我们慢慢来看。
Kubernetes项目的理论基础要比工程实践走得更靠前， kubernetes项目起源于Borg ，一个Google公司基础设施的核心系统，相比于其他的容器编排项目，它体现出了一系列的"先进性"和"完备性" ，而这些特性，成为了kubernetes项目赖以生存的核心价值。
kubernetes的问世，解决了容器的编排、调度和集群管理中的瓶颈，它解决了用户一个痛点问题：我有一个应用程序的容器镜像，请帮我在一个集群上将这个应用程序运行起来。然而，这并不足以让它替代Compose+Swarm的架构，因为docker公司原生的Compose+Swarm架构也能够解决容器的运行和基本的运维管理功能。
kubernetes更有价值的地方在于，它从一开始，就不是围绕docker这个特定的容器去设计的，它将docker仅仅看成是底层的一个容器实现，它着重解决的问题是：运行在大规模的任务之间，实际上存在着各种各样的关系，这些关系的处理，才是任务编排和系统管理最困难的地方。
这些任务之间的关系有很多类型，例如，一个web应用和MySQL数据库之间的关系、一个负载proxy和后端服务之间的关系等等。
传统的虚拟机处理这种类型的任务，通常情况是将它们部署在一起，因为各个任务之间会有tcp或者http的请求发生。但是容器技术出现之后，各个任务都可以通过镜像的方式，封装在不同的容器中，它们之间不相互干涉，拥有各自的资源配置，也可以被集群调度在不同的机器上。如下：

文章插图

02 kubernetes和Compost+Swarm之间的区别这种任务之间的关系处理，也是kubernetes项目区别于Compost+Swarm架构最明显的地方。
以web应用和MySQL这两个服务为例，在Compost+Swarm架构中，会为这两个服务中间定义一个"link" ， Docker项目会负责维护这个"link" 。Docker会在这个web应用的容器中，将DB容器的IP、port以环境变量的方法给注入进去，供应用进程使用，当DB容器的连接信息发生变化的时候，更新环境变量。
Compost+Swarm这种设计模式，可以比较好的支持web应用和MySQL的服务之间联系，但是未来可能出现更多类型的任务之间的联系，这种简单的处理依赖关系的能力，一定会遇到瓶颈。
Kubernetes 项目最主要的设计思想是：从更宏观的角度，以统一的方式来定义任务之间的各种关系，并且为将来支持更多种类的关系留有余地。
例如， Kubernetes为容器之间的相互调用进行了分类，来区分哪些交互式频繁的tcp交互，哪些交互仅仅是磁盘文件的交互等等。对于这些需要交互的任务，常规的做法是各种任务部署在同一台机器上，通过Localhost进行通信，而Kubernetes引入Service的概念，让两个本来互相依赖的服务，甚至可以部署在不同的机器上。每一个Service的背后，都是若干个Pod ， Service的作用就是为Pod提供固定的代理入口，而Pod的分布，完全是随机的。
这样，对于 Web 应用的 Pod 来说，它需要关心的就是数据库 Pod 的 Service 信息。不难想象， Service 后端真正代理的 Pod 的 IP 地址、端口等信息的自动更新、维护，则是 Kubernetes 项目的职责。
【K8S 云原生技术kubernetes简介】
03 一点总结今天我们从容器这个最基础的概念出发，提出了k8s产生的背景，又通过web应用和MySQL服务之间的“紧密协作”关系，扩展到了 Pod ，有了 Pod 之后，我们希望能一次启动多个应用的实例，这样就需要Deployment 这个 Pod 的多实例管理器(后面会讲到)；而有了这样一组相同的 Pod 后，我们又需要通过一个固定的 IP 地址和端口以负载均衡的方式访问它，于是就有了 Service ，如果web应用访问MySQL需要账号密码，我们又会引出Secret......最终，你会看到下面的一张图：

文章插图
具体的内容，我们后续慢慢分析。。。
说这么多，主要是为了表达Kubernetes 项目并没有像其他项目那样，为每一个管理功能创建一个指令，然后在项目中实现其中的逻辑。
相比之下，在 Kubernetes 项目中，我们所推崇的使用方法是：
1、首先，通过一个“编排对象” ，比如 Pod、Job、CronJob 等，来描述你试图管理的应用；
2、然后，再为它定义一些“服务对象” ，比如 Service、Secret、Horizontal Pod Autoscaler（自
动水平扩展器）等。这些对象，会负责具体的平台级功能。
这种使用方法，就是所谓的“声明式 API” 。这种 API 对应的“编排对象”和“服务对象” ，都是Kubernetes 项目中的 API 对象（API Object）。
这就是 Kubernetes 最核心的设计理念。
今天的内容就先到这里了。
以上就是云原生技术kubernetes(K8S)简介的详细内容，更多关于云原生技术 kubernetes(K8S)的资料请关注考高分网其它相关文章！