Kubernetes(k8s)

转自：https://www.cnblogs.com/menkeyi/p/7134460.html  http://www.dockone.io/article/932

实际上，使用Kubernetes只需一个部署文件，使用一条命令就能够部署多层容器（前端，后台等）的完整集群：

$ kubectl create -f single-config-file.yaml

kubectl是和Kubernetes API交互的命令行程序。

 

• Pod
• Container（容器）
• Label()（标签）
• Replication Controller（复制控制器）
• Service（）（服务）
• Node（节点）
• Kubernetes Master（Kubernetes主节点）

一、Node

Node做为集群中的工做节点，运行真正的应用程序，在Node上Kubernetes管理的最小运行单元是Pod。Node上运行着Kubernetes的Kubelet、kube-proxy服务进程，这些服务进程负责Pod的建立、启动、监控、重启、销毁、以及实现软件模式的负载均衡。

Node包含的信息：

• Node地址：主机的IP地址，或Node ID。
• Node的运行状态：Pending、Running、Terminated三种状态。
• Node Condition：…
• Node系统容量：描述Node可用的系统资源，包括CPU、内存、最大可调度Pod数量等。
• 其余：内核版本号、Kubernetes版本等。

查看Node信息：

kubectl describe node 

二、Pod

一个Pod能够看做是“逻辑宿主机”；每一个Pod里运行着一个Pause容器，其余容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，所以他们之间通讯和数据交换更为高效，在设计时咱们能够充分利用这一特性将一组密切相关的服务进程放入同一个Pod中。

一个Pod中的应用容器共享同一组资源：

• PID命名空间：Pod中的不一样应用程序能够看到其余应用程序的进程ID；
• 网络命名空间：Pod中的多个容器可以访问同一个IP和端口范围；
• IPC命名空间：Pod中的多个容器可以使用SystemV IPC或POSIX消息队列进行通讯；
• UTS命名空间：Pod中的多个容器共享一个主机名；
• Volumes（共享存储卷）：Pod中的各个容器能够访问在Pod级别定义的Volumes；

Pod的生命周期经过Replication Controller来管理；经过模板进行定义，而后分配到一个Node上运行，在Pod所包含容器运行结束后，Pod结束。

Kubernetes为Pod设计了一套独特的网络配置，包括：为每一个Pod分配一个IP地址，使用Pod名做为容器间通讯的主机名等。

 

包含一组容器和卷。Pod是短暂的，不是持续性实体。

　　数据怎么保存呢？用卷解决

　　IP会变，用Service解决。

 

三、Service

每一个Pod都会被分配一个单独的IP地址，可是会随着Pod的销毁而消失，

Service是对外访问接口，Service做用于哪些Pod是经过Label Selector来定义的。

• 拥有一个指定的名字（好比my-mysql-server）；
• 拥有一个虚拟IP（Cluster IP、Service IP或VIP）和端口号，销毁以前不会改变，只能内网访问；
• 可以提供某种远程服务能力；
• 被映射到了提供这种服务能力的一组容器应用上；

若是Service要提供外网服务，需指定：

　　公共IP

　　NodePort

　　或外部负载均衡器

NodePort 
系统会在Kubernetes集群中的每一个Node上打开一个主机的真实端口，这样，可以访问Node的客户端就能经过这个端口访问到内部的Service了

四、Volume

Volume是Pod中可以被多个容器访问的共享目录。

五、Label

Label以key/value的形式附加到各类对象上，如Pod、Service、RC、Node等，以识别这些对象，管理关联关系等，如Service和Pod的关联关系。

六、RC（Replication Controller）

• 目标Pod的定义；
• 目标Pod须要运行的副本数量；
• 要监控的目标Pod标签（Lable）；

Kubernetes经过RC中定义的Lable筛选出对应的Pod实例，并实时监控其状态和数量，若是实例数量少于定义的副本数量（Replicas），则会根据RC中定义的Pod模板来建立一个新的Pod，而后将此Pod调度到合适的Node上启动运行，直到Pod实例数量达到预约目标。

 

2、Kubernetes整体架构

Master和Node

分为Master节点和一群工做节点（Node）。

Master节点上运行着集群管理相关的一组进程etcd、API Server、Controller Manager、Scheduler，后三个组件构成了Kubernetes的总控中心，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，而且全都是自动完成。

Node节点上运行Kubelet、Proxy、Docker daemon三个组件，负责对本节点上的Pod的生命周期进行管理，以及实现服务代理的功能。

流程 
经过Kubectl提交一个建立RC的请求，该请求经过API Server被写入etcd中，

此时Controller Manager经过API Server的监听资源变化的接口监听到这个RC事件，分析以后，发现当前集群中尚未它所对应的Pod实例，因而根据RC里的Pod模板定义生成一个Pod对象，经过API Server写入etcd，

接下来，此事件被Scheduler发现，它当即执行一个复杂的调度流程，为这个新Pod选定一个落户的Node，而后经过API Server将这一结果写入到etcd中，

随后，目标Node上运行的Kubelet进程经过API Server监测到这个“新生的”Pod，并按照它的定义，启动该Pod并不辞辛苦地负责它的下半生，直到Pod的生命结束。

随后，咱们经过Kubectl提交一个新的映射到该Pod的Service的建立请求，Controller Manager会经过Label标签查询到相关联的Pod实例，而后生成Service的Endpoints信息，并经过API Server写入到etcd中，接下来，全部Node上运行的Proxy进程经过API Server查询并监听Service对象与其对应的Endpoints信息，创建一个软件方式的负载均衡器来实现Service访问到后端Pod的流量转发功能。

• etcd 
  用于持久化存储集群中全部的资源对象，如Node、Service、Pod、RC、Namespace等；API Server提供了操做etcd的封装接口API，这些API基本上都是集群中资源对象的增删改查及监听资源变化的接口。

• API Server 
  提供了资源对象的惟一操做入口，其余全部组件都必须经过它提供的API来操做资源数据，经过对相关的资源数据“全量查询”+“变化监听”，这些组件能够很“实时”地完成相关的业务功能。

• Controller Manager 
  集群内部的管理控制中心，其主要目的是实现Kubernetes集群的故障检测和恢复的自动化工做，好比根据RC的定义完成Pod的复制或移除，以确保Pod实例数符合RC副本的定义；根据Service与Pod的管理关系，完成服务的Endpoints对象的建立和更新；其余诸如Node的发现、管理和状态监控、死亡容器所占磁盘空间及本地缓存的镜像文件的清理等工做也是由Controller Manager完成的。

• Scheduler 
  集群中的调度器，负责Pod在集群节点中的调度分配。

• Kubelet 
  负责本Node节点上的Pod的建立、修改、监控、删除等全生命周期管理，同时Kubelet定时“上报”本Node的状态信息到API Server里。

• Proxy 
  实现了Service的代理与软件模式的负载均衡器。

客户端经过Kubectl命令行工具或Kubectl Proxy来访问Kubernetes系统，在Kubernetes集群内部的客户端能够直接使用Kuberctl命令管理集群。Kubectl Proxy是API Server的一个反向代理，在Kubernetes集群外部的客户端能够经过Kubernetes Proxy来访问API Server。

API Server内部有一套完备的安全机制，包括认证、受权和准入控制等相关模块。

 

Kubernetes网络模型

Kubernetes网络模型设计的一个基础原则是：每一个Pod都拥有一个独立的IP地址，并且假定全部Pod都在一个能够直接连通的、扁平的网络空间中。因此无论它们是否运行在同一个Node（宿主机）中，都要求它们能够直接经过对方的IP进行访问。设计这个原则的缘由是，用户不需额外考虑如何创建Pod之间的链接，也不须要考虑将容器端口映射到主机端口等问题。 
实际在Kubernetes的世界里，IP是以Pod为单位进行分配的。

按照这个网络抽象原则，Kubernetes对网络有什么前提和要求呢？

• 全部容器均可以在不用NAT的方式下同别的容器通讯；

• 全部节点均可以在不用NAT的方式下同全部容器通讯，反之亦然；

• 容器的地址和别人看到的地址是同一个地址；

网络通讯的场景

1. 容器到容器的通讯。 
   同一个Pod内的容器（Pod内的容器是不会跨宿主机的）共享同一个网络命名空间，共享同一个Linux协议栈。能够直接经过localhost互相访问。

2. Pod之间的通讯：同一个Node内。 
   经过Veth链接在同一个docker0网桥上，它们的IP地址都是从docker0的网桥上动态获取的，它们和网桥自己的IP3是同一个网络段的。

3. 不一样Node上的Pod之间的通讯。 
   对docker0的IP地址作统一的规划；对Pod的IP地址作统一的规划；

4. Pod到Service之间的通讯。 
   Service的虚拟IP经过每一个Node上的kube-proxy映射到不一样的Pod上，暂时只支持轮询。

5. 外部到内部的访问 NodePort、LoadBalancer。