Kubernetes的介绍

kubernetes，简称K8s，是用8代替名字中间的8个字符“ubernete”而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制。

Kubernetes应用部署方式

传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，这样做并不利于应用的升级更新/回滚等操作

通过创建虚拟机的方式来实现某些功能，但是虚拟机非常重，并不利于可移植性。

新的方式是通过部署容器方式实现，每个容器之间互相隔离，每个容器有自己的文件系统 ，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。
容器占用资源少、部署快，每个应用可以被打包成一个容器镜像，每个应用与容器间成一对一关系也使容器有更大优势，使用容器可以在build或release 的阶段，为应用创建容器镜像，因为每个应用不需要与其余的应用堆栈组合，也不依赖于生产环境基础结构，这使得从研发到测试、生产能提供一致环境。类似地，容器比虚拟机轻量、更“透明”，这更便于监控和管理。

Kubernets系统简介

首先，他是一个全新的基于容器技术的分布式架构领先方案。Kubernetes(k8s)是Google开源的容器集群管理系统（内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。
　　Kubernetes是一个完备的分布式系统支撑平台，具有完备的集群管理能力，多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。同时Kubernetes提供完善的管理工具，涵盖了包括开发、部署测试、运维监控在内的各个环节。

Kubernetes中，Service是分布式集群架构的核心，一个Service对象拥有如下关键特征：
拥有一个唯一指定的名字
拥有一个虚拟IP（Cluster IP、Service IP、或VIP）和端口号
能够体统某种远程服务能力
被映射到了提供这种服务能力的一组容器应用上

Service的服务进程目前都是基于Socket通信方式对外提供服务，比如Redis、Memcache、MySQL、Web Server，或者是实现了某个具体业务的一个特定的TCP Server进程，虽然一个Service通常由多个相关的服务进程来提供服务，每个服务进程都有一个独立的Endpoint（IP+Port）访问点，但Kubernetes能够让我们通过服务连接到指定的Service上。有了Kubernetes内奸的透明负载均衡和故障恢复机制，不管后端有多少服务进程，也不管某个服务进程是否会由于发生故障而重新部署到其他机器，都不会影响我们队服务的正常调用，更重要的是这个Service本身一旦创建就不会发生变化，意味着在Kubernetes集群中，我们不用为了服务的IP地址的变化问题而头疼了。
　　容器提供了强大的隔离功能，所有有必要把为Service提供服务的这组进程放入容器中进行隔离。为此，Kubernetes设计了Pod对象，将每个服务进程包装到相对应的Pod中，使其成为Pod中运行的一个容器。为了建立Service与Pod间的关联管理，Kubernetes给每个Pod贴上一个标签Label，比如运行MySQL的Pod贴上name=mysql标签，给运行PHP的Pod贴上name=php标签，然后给相应的Service定义标签选择器Label Selector，这样就能巧妙的解决了Service于Pod的关联问题。
　　在集群管理方面，Kubernetes将集群中的机器划分为一个Master节点和一群工作节点Node，其中，在Master节点运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力，并且都是全自动完成的。Node作为集群中的工作节点，运行真正的应用程序，在Node上Kubernetes管理的最小运行单元是Pod。Node上运行着Kubernetes的kubelet、kube-proxy服务进程，这些服务进程负责Pod的创建、启动、监控、重启、销毁以及实现软件模式的负载均衡器。
　　在Kubernetes集群中，它解决了传统IT系统中服务扩容和升级的两大难题。你只需为需要扩容的Service关联的Pod创建一个Replication Controller简称（RC），则该Service的扩容及后续的升级等问题将迎刃而解。在一个RC定义文件中包括以下3个关键信息。
目标Pod的定义
目标Pod需要运行的副本数量（Replicas）
要监控的目标Pod标签（Label）

在创建好RC后，Kubernetes会通过RC中定义的的Label筛选出对应Pod实例并实时监控其状态和数量，如果实例数量少于定义的副本数量，则会根据RC中定义的Pod模板来创建一个新的Pod，然后将新Pod调度到合适的Node上启动运行，知道Pod实例的数量达到预定目标，这个过程完全是自动化。

Kubernetes优势:
- 容器编排
　　　　 - 轻量级
　　　　 - 开源
　　　　 - 弹性伸缩
　　　　 - 负载均衡

Kubernetes 特性
1.Endpoint Slices
Kubernetes 集群中网络端点的可扩展跟踪。
2.服务发现与负载均衡
无需修改您的应用程序即可使用陌生的服务发现机制。Kubernetes 为容器提供了自己的 IP 地址和一个 DNS 名称，并且可以在它们之间实现负载平衡。
3.自我修复
重新启动失败的容器，在节点死亡时替换并重新调度容器，杀死不响应用户定义的健康检查的容器，并且在它们准备好服务之前不会它们公布给客户端。
4.自动装箱
根据资源需求和其他约束自动放置容器，同时不会牺牲可用性，将任务关键工作负载和尽力服务工作负载进行混合放置，以提高资源利用率并节省更多资源。
5.IPv4/IPv6 双协议栈
Allocation of IPv4 and IPv6 addresses to Pods and Services
6.水平伸缩
使用一个简单的命令、一个UI或基于CPU使用情况自动对应用程序进行伸缩。
 

Kubernetes的Master和Node节点
1.Master
k8s集群的管理节点，负责管理集群，提供集群的资源数据访问入口。拥有Etcd存储服务（可选），运行Api Server进程，Controller Manager服务进程及Scheduler服务进程，关联工作节点Node。Kubernetes API server提供HTTP Rest接口的关键服务进程，是Kubernetes里所有资源的增、删、改、查等操作的唯一入口。也是集群控制的入口进程；Kubernetes Controller Manager是Kubernetes所有资源对象的自动化控制中心；Kubernetes Schedule是负责资源调度（Pod调度）的进程

Master核心组件：

1)API Server。集群控制的唯一入口，它是各个组件通信的中心枢纽。

2)controller-mananger。负责编排，用于调节系统状态。内置了多种控制器（DeploymentController、ServiceController、NodeController、HPAController等）是Kubernetes维护业务和集群状态的最核心组件。

3)scheduler。集群的调度器，它负责在Kubernetes集群中为Pod资源对象找到合适节点并使其在该节点上运行。

4)etcd。用于存储Kubernetes集群的数据与状态信息。

Kubernetes架构具备高可用：一方面Master节点高可用；另一方面所部署的业务也是高可用的。系统高可用的核心在于冗余部署，当某一个节点或程序出现异常时，其他节点或程序能分担或替换工作。
Master节点高可用，主要由以下几个方面的设计实现：
1）Master由多台服务器构成
2）API Server多实例同时工作，负载均衡
3）etcd多节点，一主多从
4）controller-manager与scheduler抢主实现

2.Node
Node是Kubernetes集群架构中运行Pod的服务节点（亦叫agent或minion）。Node是Kubernetes集群操作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机。关联Master管理节点，拥有名称和IP、系统资源信息。运行docker eninge服务，守护进程kunelet及负载均衡器kube-proxy.
每个Node节点都运行着以下一组关键进程
kubelet：负责对Pod对于的容器的创建、启停等任务
kube-proxy：实现Kubernetes Service的通信与负载均衡机制的重要组件
Docker Engine（Docker）：Docker引擎，负责本机容器的创建和管理工作

Node节点可以在运行期间动态增加到Kubernetes集群中，默认情况下，kubelet会想master注册自己，这也是Kubernetes推荐的Node管理方式，kubelet进程会定时向Master汇报自身情报，如操作系统、Docker版本、CPU和内存，以及有哪些Pod在运行等等，这样Master可以获知每个Node节点的资源使用情况，冰实现高效均衡的资源调度策略。

4. Kubernetes Node运行节点，运行管理业务容器，包含如下组件:
（1）Kubelet
负责管控容器，Kubelet会从Kubernetes API Server接收Pod的创建请求，启动和停止容器，监控容器运行状态并汇报给Kubernetes API Server。

（2）Kubernetes Proxy
负责为Pod创建代理服务，Kubernetes Proxy会从Kubernetes API Server获取所有的Service信息，并根据Service的信息创建代理服务，实现Service到Pod的请求路由和转发，从而实现Kubernetes层级的虚拟转发网络。

API Server中心枢纽
Kubernetes中API Server的核心功能是提供Kubernetes各类资源对象（如Pod、RC、Service等）的增、删、改、查及Watch等HTTP REST接口，成为集群内各个功能模块之间数据交互和通信的中心枢纽，是整个系统的数据总线和数据中心。除此之外，它还是集群管理的API入口，提供了完备的集群安全机制。API Server是由多实例同时工作，各个组件通过负载均衡连到具体的API Server实例上。
如下所示，各组件与API Server通信时，采用List-Watch机制，通过API server获取etcd配置与状态信息，进而触发行为。以下图为例是kubectl创建一个deployment时，各个组件与API Server的流程交互。

Api Server的作用：
1）集群控制、访问的唯一入口，统一的认证、流量控制、鉴权等。
2）ectd数据的缓存层，请求不会轻易穿透到etcd。
3）集群中各个模块的中心枢纽，各个模块之间解耦。
4）便于模块插件的扩展（其他模块List、Watch、Update ApiServer即可实现扩展功能）。

Kubernetes核心设计
Kubernetes取的巨大的成功，与它良好的核心设计紧密相关。笔者认为Kubernetes有三大核心设计：
1)编排抽象。容器平台核心点不在于创建和调度容器，而是在上层架构抽象出各种对象，便于去统一管理。Kubernetes创造性的抽象出了各个编排的关系，例如亲密关系(Pod对象)、访问关系（Service对象）等.

2)声明式API。声明式API是整个系统自动化的核心要点，kubernetes提供了以声明式API的方式将抽象对外暴露，同时也便于了用户管理对象。

3)开发插件。支持系统资源插件化（比如计算、存储、网络）；同时也支持用户自定义CRD和开发Operator。

Pod对象
Kubernetes在对象抽象方面，核心创新在于Pod对象的设计。容器设计本身是一种“单进程”模型。该表述不是指容器里只能启动一个进程，而是指容器无法管理多个进程。只有容器内PID=1的进程生命周期才受到容器管理（该进程退出后，容器也会退出），其他进程都是PID=1的进程的子进程。根据容器设计模式，传统架构中多个紧密配合的业务进程（例如业务进程与日志收集进程，业务进程与业务网络代理进程）应该部署成多个容器。但这些容器之间存在亲密的关系，需要一起调度和直接共享某些资源（网络和存储）。
Kubernetes抽象出一个Pod对象，是一组（一个或多个）容器， 这些容器共享存储、网络等， 这些容器是相对紧密的耦合在一起的。Pod是Kubernetes内创建和管理的最小可调度单元，调度过程是按Pod整体所需资源一起进行调度的。Pod本身只是逻辑上的概念，在容器管理这层并不认识Pod对象。
Pod的实现需要使用一个中间容器（Infra容器），在这个Pod中，Infra容器永远是第一个被创建的容器，用户定义的其他容器通过Join Network Namespace的方式与Infra容器关联在一起。抽象一个中间容器的原因在于各个业务容器是对等的，其启动没有严格的先后顺序，需借助中间容器实现共享网络和存储的目的。