kubernetes介绍-01

云计算与K8s的关系

• 其实在我们看到分类这一块，不管是应用、环境、或者是硬件资源的限制，都面临着一些问题，最典型的就是环境的不统一，如果开发人员，所使用的环境，跟我们最终上架部署时的环境不统一就容易出现各种问题，那么这时候，docker就横空出世了，他可以将我们所需要的环境进行封装，封装成一个镜像，然后我们的开发人员在以这个镜像为基础的容器里发布代码，然后我们再将它制作成镜像，就可以解决环境不统一的问题了。
• docker的出现，可以说是一个必然的产物，很显然，docker公司抓住了这次机会，到后来，步入到容器世界这个新领域之后，慢慢的发现，我们对容器的要求越来越高，尤其企业级应用开发更是需要基于容器技术，实现支持多人协作的持续集成、持续交付等，这个时候kubernetes就又出现了。

kubernetes介绍

• 其实k8s出现的时间那，并不长，只有区区几年的时间，就像是一个舵手，飞行员，是谷歌开发的，基于GO语言，大概是在2014年对外宣布，所以到今年为止也就5年时间，k8s的前身，其实是谷歌内部一个集群管理编排系统，叫Borg（博格），它其实已经用了10几年的时间了，可以说人们都知道谷歌有这种技术，但无奈人家是闭源的，自己用的，可以说是觊觎已久，可惜始终没有办法一窥究竟。后来那，随着容器技术的发展，谷歌发现，这项技术的话语权可能要暴露的时候拿，谷歌索性用GO语言，从头开始从写了一个程序，就这短短几年的时间，k8s的发展非常迅速，尤其是k8s这种新兴技术领域，我们的国人，倾入了大量的心血，非常不容易，不仅是我国，因为大家都知道k8s是基于谷歌的borg系统而来的，可以说是吸引了的目光，不过它那也确实，没有辜负了大家对它的这份期望。
• K8s的1.0版本，大概是在2015年7月份左右发布，到现在也就4年时间，到现在那，它的版本已经到了 1.13，差不多1年3、4个版本的迭代。我们不妨去github上去看下一它的源码, https://www.github.com/kubernetes。
• 在2017年，是容器发展历程上具有里程碑意义的一年，因为在这一年当中，AWS（亚马逊云）,微软的云（Azure）,还有我们的阿里云等著名的云计算公司，陆续宣布，他们的云环境那原生态支持K8S，也就是说，购买了云服务的用户，只要点击一个按钮，直接就可以快速生成K8S集群环境供用户使用，这些大公司的引用，说明了咱们k8s的已经收到了广泛的认可。而且2017年10月份左右，docker公司宣布那，在docker总网同时支持swarm和k8s两种工具，swarm是docker拿来跟k8s竞争的，后来k8s太过受欢迎，到后来不得不在发型的企业版本中原生支持k8s。

以上那，是我们k8s的一个发展的历史，以及我们知道了k8s在未来是多么的重要，那么为什么他会这么受欢迎那？都说它是一个容器编排工具，那么它到底能够实现哪方面那？特性有哪些？

1. 自我修复：就是有自愈能力。就是说，一旦一个容器蹦了，出问题了，K8S它真的会去自动找到这个坏的容器，然后分析它到底哪里出现了问题，再去修复它，重启，是这样么？不是的，它的策略是，一个出现问题之后，直接干掉，然后生成一个新的做一个替换，它是这样一种修复方式。所以我们从这里也应该发现一个趋势，就是我们的关注点，已经像群体，集群的方式转变，而不再是个体了。
2. 自动实现水平扩展。一个容器不够，再建一个，还不够再建一个，只要你的物理资源允许的情况下，可以不断的扩展。这个很好理解啊。
3. 自动化的服务发现和负载均衡。当我们需要在k8s运行很多应用程序的时候，好比我们运行的是各种的微服务，如果一个微服务依赖于其他的一个微服务，它能够通过这种自动找到他所依赖的服务，并且如果需要启动多个容器的话，还能够实现自动的负载均衡。后边咱们会仔细将他们是怎么实现的。
4. 自动发布和回滚，作为以后的一名运维人员那，这是我们的一个日常运维任务。有了k8s之后，你就省事多了。
5. 秘钥和配置管理，假设说，我们现在分别运行了20个nginx，有一天那，需要对他们的配置文件进行改动，我们怎么做那？一台一台配置么？我们会利用ansible等一些工具，编写脚本等方法来实现，可这最终还是需要我们人工操作，那么k8s是怎么实现的那？每个服务在启动的时候，都会加载自己配置文件，一遍都是放在本地的，但K8s不是这样做的，它设立了一个专门配置管理服务器，刚才这20个nginx他们启动的时候，不在是通过加载自己本地的配置文件启动，而是先到配置服务器上加载信息，这样做有什么好处那？配置的集中化，也就是说，以后我们想要改配置文件，只需要改配置服务器，也就是我们配置中间这里就可以了
6. 存储编排
7. 任务的批量处理执行

kubernetes架构及原理

我们要知道，k8s集群环境中，有master 和node之分，master作为主节点，又有3个功能主键，APIserver，scheduler,controller-Manager.那么node节点有3个，一个kuberlet，作为集群角色的核心主键，其实就是负责跟APIserver通信的一个核心主键。Docker是在pod里面运行容器的。关于这个pod大家一定要有一个概念，作为k8s逻辑上的最小单元，其实那，它也是一个容器，只不过因为pod里面可以运行单个或多个docker，所以说k8s在这点上做的比较严谨。一个集群会有大量pod，为了更好的管理这些pod，K8s又给Pod定义了元素类信息，label,一种KV，label:key=value格式的数据。而且在k和v上还有一定的限制，定义完以后那，我们还可以用Label selector（标签选择器）:通过过滤条件，来挑选出符合要求的pod资源。
接下来那，让我们来更深入的来理解它的一些其他的概念。
比如说，在k8s之上，我们运行了容器之后，同一类容器，或者说同一类pod可能不止一个，是吧？那么既然如此，有两个问题，第一：当用户的请求到达时，我们改如何接纳用户的请求，到底由后边同一类pod里面那个pod来负责和响应，第二：pod是要有控制器来管理，尽量不要人工手工参与操作，事实上在k8s上，pod有两类，这个两类的，官方上是并没有给出定义的，是我们自己给它分的类，第一类叫：自助式pod：自我管理的，我们创建以后，仍然是需要提交给APIserver，由APIserver接受以后，借助于调度器来调度node节点，由node启动此pod，如果有容器出现故障，需要重启容器，那么就kubelet来完成，但是如果node节点故障，那么pod就消失了，也就是说容器就消失了，不能工作了。所以它还有这样一个弊端。所以我们推荐大家使用第二类Pod：是有控制器来参与管理的pod。也正式因为有控制器这种机制的使用，来管理参与创建Pod,所以在k8s集群中设计中，pod完全可以叫做有生命周期的对象。然后，由控制器来调度pod将其调度至集群中的某节点，运行以后，任务终止，进程也就被删除，也就没有了。但是传统意义上像我们启动一个tomcat和一个nginx的话，他们完成启动任务之后，会作为守护进程来运行的，也就是说如果发现他有问题的话，有可能是要进程重启之类的操作。如果这一切都要我们人工来进行监控，甚至一些监控软件都很难来实现，毕竟作为软件开发而言，你软件本身就应该有这样的功能，所以咱们k8s的这个功能就叫pod控制器。这种pod控制器有很多种，最早的一种，ReplicationController:副本控制器，意思是，当我们启动一个pod，比如是一个nginxpod，那么如果这一个pod不够了，那么我们就需要再启动一个，那么这个pod就叫做副本，其实每一个都可以成为副本，那么控制器，就控制着同一类资源的各种pod对象和副本，一旦发现副本数量少了，那么它会跟APIserver请求，APIserver再通过调度器scheduler添加一个，同理如果多了一个，也会删除。这个处理方式那叫做多退少补。为的是要精确符合我们用户的定义。比方说我们现在运行着两个，其中一个坏了，就会通过APIserver添加一个新的，这里我么暂且不说，他们的数据之间的迁移，只看这个副本的数量，它是保持着跟原来定义的是一样的。
我们的replicationcontroller就是来实现这个功能的，它还能实现什么功能的？比如滚动更新，比如我们公司现在运行的服务是1.0镜像版本启动的，现在我们需要做一次大的升级，要把它变成1.1版本。这个时候就需要我们把运行在pod容器里的docker镜像替换成1.1版本，我们怎么做那？这个时候就用到我们的滚动更新了。需要怎么做那?比如说运行的有2个副本，我们可以先关闭一个副本，当然也可以不关，那么我们在更新的时候能先创建一个新的副本，原先不是定义说只运行两个副本吗？在更新的时候是可以临时添加副本的，那么我们的新副本创建完成之后，再删除之前的老版本，以此类推，直到全部更新完成，这就叫滚动更新。这里注意一点，我们不仅可以替换新的版本，而且还可以把旧版本在替换回来，那么这叫回滚操作。这个那就是早期的pod控制器，到后面那，k8s推出了一个叫ReplicaSet（叫副本集控制器），但ReplicaSet不直接使用，他有一个声明式控制器，叫Deployment来负责管理，但Deployment只能用来负责管理那么无状态的应用，什么叫无状态服务，什么叫有状态服务，在这里那，先不跟你们深说，你们现在先可以这么理解，无状态的服务，它是没有做数据持久化的操作的，有状态的服务，是有一部分数据可以做持久化，具体的我们现在不说，以后，我们会有类似的实验。另外我们的Deployment控制器还支持二级控制器进程叫HPA，叫水平pod自动伸缩控制器，这个跟我们上面所说说的那个多退少补，是差不多类似的，比如说我们后边定义的是后边运行服务对CPU利用率不成超过60%，但现在明显2个POD无法满足，那么它就会自动增加POD数量，至于增加几个，那就要经过计算机的计算了。但现在明显2个刚才说了无状态，那么有状态的就是statefulset，另外，如果我们需要只每一个node几点上，运行一个副本，而不是随意运行那么就需要DaemonSet,job,Ctonjob周期性作业，这些那就是常见的控制器，光pod控制器就这么一大推，而我们刚才提到的job和Ctonjob只是为了完成某些特定任务来指定的，job完成一次性的作业，例如日志备份，备份完成之后，job消失。那么Ctonjob用于特定操作，而且时间不太固定，比如我们现在生成了一大堆的数据集，需要我们做一个清理，临时的启动一个pod来执行这个清理动作，那么这个就叫做job，任务完成，job消失，所以这么多pod管理器，是用来分别对应不同的服务来指定的，以便于更好的服务于用户。
kubernetes这个名字起源于古希腊，是舵手的意思，所以它的logo既像一张渔网，又像一个罗盘。 Kubernetes是一个为了自动化部署、扩展伸缩和管理容器应用的开源系统。 它将组成应用程序的容器组合成逻辑单元，便于管理和发现。Kubernetes是建立在15年谷歌的生产运行的工作经验上的，并且从社区结合了佳的想法和做法。 同时支持两种容器技术：Docker和Rocket（CoreOS）
他是一个全新的基于容器技术的分布式架构领先方案。Kubernetes(k8s)是 Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化 的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容 器集群管理的便捷性

Master节点

Master节点上面主要由四个模块组成：APIServer、scheduler、controller manager、etcd
Master是集群的网关和中枢，负责诸如为用户和客户端暴露API、跟踪其他服务器的健康状态、以最优方式调度工作负载，以及编排其他组件之间的核心联络点，并负责kubernetes系统的大多数集中式管控逻辑。单个master节点即可完成其所有的功能，但出于冗余及负载均衡的目的，生产环境中通常需要协同部署多个此类主机。Master节点类似于蜂群中的蜂王。
APIServer。
APIServer负责对外提供RESTful的Kubernetes API服务，它是系统管理指令的统一入口，任何对资源进行增删改查的操作都要交给APIServer处理后再提交给etcd。kubectl（Kubernetes提供的客户端工具，该工具内部就是对 Kubernetes API的调用）是直接和APIServer交互的
Scheduler
scheduler的职责很明确，就是负责调度pod到合适的Node上。如果把scheduler看成一个黑匣子，那么它的输入是pod和由多个Node组成的列表，输出是 Pod和一个Node的绑定，即将这个pod部署到这个Node上。Kubernetes目前提供了调度算法，但是同样也保留了接口，用户可以根据自己的需求定义自己的调度算法
controller manager
如果说APIServer做的是“前台”的工作的话，那 controller manager就是负责“后台”的。每个资源一般都对应有一个控制器，而 controller manager就是负责管理这些控制器的。比如我们通过APIServer创建一个pod， 当这个pod创建成功后，APIServer的任务就算完成了。而后面保证Pod的状态始终和我们 预期的一样的重任就由controller manager去保证了
etcd
etcd是一个高可用的键值存储系统，Kubernetes使用它来存储各个资源的 状态，其实不仅能够提供键值数据存储，而且还为其提供了监听机制。kubbernetes系统中，etcd中的键值发生变化时会通知到APIserver，并由其通过watchAPI向客户端输出。基于watch机制，kubernetes集群的各组件实现了高效协同合作。

Node

Nodde负责提供运行容器的各种依赖环境，并接受Master的管理。
每个Node节点主要由三个模块组成：kubelet、kube-proxy、runtime
runtime
runtime指的是容器运行环境，目前Kubernetes支持docker和rocket 两种容器，它负责下载镜像和运行容器。kubelet并未固定链接至某容器运行时环境，而时以插件的方式载入配置的容器环境。
kube-proxy
该模块实现了Kubernetes中的服务发现和反向代理功能。反向代理方面：kube-proxy支持TCP和UDP连接转发，默认基于Round Robin算法将客户端流量 转发到与service对应的一组后端pod。服务发现方面，kube-proxy使用etcd的watch机 制，监控集群中service和endpoint对象数据的动态变化，并且维护一个service到 endpoint的映射关系，从而保证了后端pod的IP变化不会对访问者造成影响。另外kubeproxy还支持session affinity。
kubelet
Kubelet是Master在每个Node节点上面的agent，是Node节点上面 重要的模块，它负责维护和管理该Node上面的所有容器，负责Pod对应的容器的创建、启 停等任务。但是如果容器不是通过Kubernetes创建的，它并不会管理。本质上，它负责使 Pod得运行状态与期望的状态一致

至此，Kubernetes的Master和Node就简单介绍完了。下面我们来看Kubernetes中的各种资源/对象

Pod 　
　Pod 是Kubernetes的基本操作单元，也是应用运行的载体。整个Kubernetes系统都是 围绕着Pod展开的，比如如何部署运行Pod、如何保证Pod的数量、如何访问Pod等。另 外，Pod是一个或多个相关容器的集合，这可以说是一大创新点，提供了一种容器的组合的 模型。

除了基础的组件之外，通常一个完整的kubernetes集群还会由一组“附件”，那么这些附件，通常时第三方提供的特定应用程序。
KubeDNS
在kubernetes集群中调度运提供DNS服务的Pod，同一集群中的其他Pod可使用此DNS服务解决主机名，Kubernetes自1.11版本开始默认使用CoreDNS项目为集群提供服务注册和服务发现的动态名称解析服务，之前的版本中用到的是kube-dns项目，而SkyDNS则是更早一代的项目
Kuberenets Dashboard
Kubernets集群的全部功能都要给予Web的UI来管理集群中的应用甚至是集群自身
Heapster
容器和节点的性能监控和分析系统，收集并解析多种指标数据，如资源利用率、生命周期时间等，新版本的Kubernetes中，其功能会逐渐有Prometheus结合其他组件所取代
Ingress Controller
Server是一种工作于传统层的负载均衡器，而Ingress是在应用层实现的HTTP(s)负载均衡机制，不过Ingrress资源自身并不能进行“流量穿透”，它仅是一组路由规则的集合，这些规则需要通过Ingress控制器（ingress Controller）发挥作用，目前，此类的可用项目有Nginx、Traefik、Envoy及HAProxy