Kubernetes 总结

1.Kubernetes 是什么？

首先，它是一个全新的基于容器技术的分布式架构领先方案。

其次，Kubernetes 是一个开放的开发平台。它不局限于任何一种语言，没有限定任何编程接口，所以不论是用Java、Go、C++ 还是用 Python 编写的服务，都可以毫无困难地映射为Kubernetes 的 Service ，并通过标准的 TCP 通信协议进行交互。

最后， Kubernetes 是一个完备的分布式系统支撑平台。
Kubernetes 具有完备的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制，以及多粒度的资源配额管理能力。
同时，Kubernetes 提供了完善的管理工具，这些工具涵盖了包括开发、部署测试、运维监控在内的各个环节。

因此， Kubernetes 是一个全新的基于容器技术的分布式架构解决方案，并且是一个一站式的完备的分布式系统开发和支撑平台。

2.kubernetes 架构与组件

在集群管理方面， Kubernetes 将集群中的机器划分为一个Master节点和一群工作节点（ Node ） 。其中，在Master 节点上运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler ，这些进程实现了整个集群的资源管理、Pod 调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，井且都是全自动完成的。Node 作为集群中的工作节点，运行真正的应用程序，在Node 上 Kubernetes 管理的最小运行单元是Pod 。Node 上运行着 Kubernetes 的kubelet 、kube-proxy 服务进程，这些服务进程负责Pod 的创建、启动、监控、重启、销毁，以及实现软件模式的负载均衡器。

两类节点：Master 和 Node

Kubernetes 里的Master 指的是集群控制节点， 每个Kubernetes 集群里需要有一个Master节点来负责整个集群的管理和控制，基本上Kubernetes 的所有控制命令都发给它，它来负责具体的执行过程，我们后面执行的所有命令基本都是在Master 节点上运行的。Master 节点通常会占据一个独立的服务器（ 高可用部署建议用3 台服务器） ， 其主要原因是它太重要了，是整个集群的“ 首脑” ，如果岩机或者不可用，那么对集群内容器应用的管理都将失效。

（一）Master节点(集群大脑)上运行：
        API Server：提供了HTTP Rest 接口的关键服务进程，是Kubernetes 里所有资源的增、删、改、查等操作的唯一入口，也是集群控制的入口进程。

        Scheduler：负责资源调度(Pod 调度)的进程，为Pod找到一个合适的Node。

        Controller Manager：Kubernetes 里所有资源对象的自动化控制中心，可以理解为资源对象的“大总管”。

        etcd：kubernetes集群的主数据库，Kubernetes 里的所有资源对象的数据全部是保存在etcd 中。

API Server:提供了资源对象的唯一操作入口，其他所有组件都必须通过他提供的API来操作资源数据，通过对相关的资源数据“全量查询”+“变化监听”，这些组件可以很“实时”地完成相关的业务功能，比如某个新的Pod一旦被提交到API Server 中，controller Manager 就会立即发现并开始调度。

提供了HTTP Rest 接口的关键服务进程，是Kubernetes 里所有资源的增、删、改、查等操作的唯一入口，也是集群控制的入口进程。

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

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

etcd：数据库，用于存储有关 Kubernetes 对象，其当前状态，访问信息和其他集群配置信息的所有数据。

Node 节点才是Kubernetes 集群中的工作负载节点， 每个Node 都会被Master 分配一些工作负载（ Docker 容器），当某个Node 岩机时，其上的工作负载会被Master 自动转移到其他节点上去。


（二）Ndoe节点上运行：
        kubelet：负责Pod 对应的容器的创建、启停等任务，同时与Master 节点密切协作， 实现集群管理的基本功能。

        kube-Proxy：实现Kubernetes Service 的通信与负载均衡机制的重要组件。

        Docker dadmon：Docker 引擎，负责本机的容器创建和管理工作。

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

kubelet 组件，Master和Node之间的桥梁

Node 节点可以在运行期间动态增加到 Kubernetes 集群中，在默认情况下 kubelet 会向Master 注册自己，这也是Kubernetes推荐的Node 管理方式。一旦Node 被纳入集群管理范围， kubelet 进程就会定时向Master 节点汇报自身的情报，例如操作系统、Docker 版本、机器的CPU 和内存情况，以及当前有哪些Pod在运行等， 这样Master 可以获知每个Node 的资源使用情况，并实现高效均衡的资源调度策略。而某个Node 超过指定时间不上报信息时，会被Master 判定为“失联”， Node 的状态被标记为不可用（ Not Ready ），随后Master 会触发“工作负载大转移”的自动流程。

kube-proxy：实现了Service 的代理及软件模式的负载均衡器。
1）运行在每个Node之上
2）代理每个服务的请求

Kube-proxy是一个简单的网络代理和负载均衡器。他具体实现Service模型，每个Service都会在所有的Kube-proxy节点上体现。根据Service的selector所覆盖的Pods,Kube-proxy会对这些Pods做负载均衡来服务于Service

Docker Engine ( docker) : Docker 引擎，负责本机的容器创建和管理工作。

Node 节点可以在运行期间动态增加到 Kubernetes 集群中，前提是这个节点上己经正确安装、配置和启动了上述关键进程，在默认情况下 kubelet 会向 Master 注册自己，这也是Kubernetes推荐的Node 管理方式。一旦 Node 被纳入集群管理范围， kubelet 进程就会定时向 Master 节点汇报自身的情报，例如操作系统、Docker 版本、机器的CPU 和内存情况，以及当前有哪些Pod在运行等， 这样 Master 可以获知每个Node 的资源使用情况，并实现高效均衡的资源调度策略。而某个Node 超过指定时间不上报信息时，会被 Master 判定为“失联”， Node 的状态被标记为不可用（ Not Ready ），随后Master 会触发“工作负载大转移”的自动流程。






Service：

Service 的服务进程目前都基于Socket 通信方式对外提供服务，虽然一个Service 通常由多个相关的服务进程来提供服务，每个服务进程都有一个独立的Endpoint( IP+Port ）访问点，但Kubernetes 能够让我们通过Service （虚拟Cluster IP +Service Port〉连接到指定的Service 上。有了 Kubernetes 内建的透明负载均衡和故障恢复机制，不管后端有多少服务进程，也不管某个服务进程是否会由于发生故障而重新部署到其他机器，都不会影响到我们对服务的正常调用。更重要的是这个Service 本身一旦创建就不再变化，这意味着在Kubernetes集群中，我们再也不用为了服务的 IP 地址变来变去的问题而头疼了。

容器提供了强大的隔离功能，所以有必要把为 Service 提供服务的这组进程放入容器中进行隔离。为此，Kubernetes 设计了Pod 对象，将每个服务进程包装到相应的Pod 中，使其成为Pod中运行的一个容器（ Container ）。为了建立Service 和Pod 间的关联关系， Kubemetes 首先给每个Pod 贴上一个标签（ Label) ，比如给运行MySQL 的Pod 贴上name=mysql 标签，然后给相应的Service 定义标签选择器（ Label Selector ），比如MySQL Service 的标签选择器的选择条件为 name=mysql ，意为该Service 要作用于所有包含name=mysql Label 的 Pod 上。这样一来，就巧妙地解决了Service 与Pod 的关联问题。

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

Service一个应用服务抽象，定义了Pod逻辑集合和访问这个Pod集合的策略

Service代理Pod集合对外表现是为一个访问入口，分配一个集群IP地址，来自这个IP的请求将负载均衡转发后端Pod中的容器，也就是Service 定义了一个服务的访问入口地址，前端的应用( Pod ）通过这个入口地址访问其背后的一组由Pod 副本组成的集群实例，Service 与其后端Pod副本集群之间则是通过Label Selector 来实现“无缝对接”的。而RC 的作用实际上是保证Service的服务能力和服务质量始终处于预期的标准。

Service通过Label Selector选择一组Pod提供服务

Service 的服务进程目前都基于Socket 通信方式对外提供服务。

Service不是共用一个负载均衡器的 IP地址，而是每个Service 分配了一个全局唯一的虚拟IP 地址，这个虚拟IP 被称为 Cluster IP，而且在Service 的整个生命周期内，它的Cluster IP 不会发生改变。这样一来，每个服务就变成了具备唯一 IP地址的“通信节点”，服务调用就变成了最基础的 TCP 网络通信问题。而且服务发现这个棘手的问题在Kubernetes 的架构里也得以轻松解决：只要用Service 的 Name 与Service 的 Cluster IP 地址做一个DNS 域名映射即可完美解决问题。

Service 的 Cluster IP ，它也是一个虚拟的IP ，原因有以下几点：
1）Cluster IP 仅仅作用于Kubernetes Service 这个对象，并由Kubernetes管理和分配IP 地址（来源于Cluster IP 地址池）。
2) Cluster IP 无法被Ping ， 因为没有一个“实体网络对象”来响应。
3) Cluster IP 只能结合Service Port 组成一个具体的通信端口，单独的 Cluster IP 不具备 TCP/ IP 通信的基础， 并且它们属于 Kubernetes 集群这样一个封闭的空间， 集群之外的节点如果要访问这个通信端口，则需要做一些额外的工作。
4) 在Kubernetes 集群之内， Node IP 网、Pod IP 网与Cluster IP 网之间的通信， 采用的是Kubernetes 自己设计的一种编程方式的特殊的路由规则，与我们所熟知的 IP路由有很大的不同。


Pod：

Pod 是Kubernetes 的最重要也最基本的概念，Pod 是最小部署单元，一个Pod有一个或多个容器组成，Pod中容器共享存储和网络，在同一台主机上运行。每个Pod 都有一个特殊的被称为“根容器”的Pause 容器。Pause 容器对应的镜像属于Kubernetes平台的一部分，除了Pause 容器，每个Pod 还包含一个或多个紧密相关的用户业务容器。

Kubernetes 为每个Pod 都分配了唯一的 IP 地址，称之为Pod IP ， 一个Pod 里的多个容器共享Pod IP 地址。Kubernetes 要求底层网络支持集群内任意两个Pod 之间的TCP/IP 直接通信，这通常采用虚拟二层网络技术来实现，例如Flannel 、Open vSwitch 等，因此我们需要牢记一点：在Kubernetes 里， 一个Pod 里的容器与另外主机上的 Pod 容器能够直接通信。

普通的 Pod 一旦被创建，就会被放入到 etcd 中存储，随后会被Kubernetes Master调度到某个具体的Node 上并进行绑定（ Binding ），随后该Pod 被对应的Node 上的kubelet 进程实例化成一组相关的 Docker 容器并启动起来。在默认情况下，当Pod 里的某个容器停止时，Kubernetes 会自动检测到这个问题并且重新启动这个Pod （重启Pod 里的所有容器），如果Pod所在的Node 岩机，则会将这个Node 上的所有Pod 重新调度到其他节点上。

Pod的生命周期是通过Replication Controller(RC)来管理的。

Replication Controller：

Replication Controller是Kubernetes系统的核心概念，用于定义Pod副本的数量。
在Master内，Controller Manager进程通过RC的定义来完成Pod的创建、监控、启停等操作。

在Kubernetes集群中，只需为需要扩容的Service关联的Pod创建一个RC（Replication Controller），则该Service的扩容以及升级等问题都可迎刃而解。在一个RC定义文件中包括以下3个关键信息：
(1)目标Pod的定义
(2)目标Pod需要运行的副本数量（Replicas）
(3)要监控的目标Pod的标签（Label）

定义了一个 RC 并提交到 Kubernetes 集群中以后， Master 节点上的 Controller Manager组件就得到通知，通过RC定义的Label筛选出对应的Pod实例，定期巡检系统中当前存活的目标 Pod 的状态和数量，并确保目标Pod 实例的数量刚好等于此 RC 的期望值，如果有过多的 Pod 副本在运行，系统就会停掉一些Pod ；如果实例数量少于定义的副本数量（Replicas）,则会根据RC中定义的Pod模板来创建一个新的Pod，然后将此Pod调度到合适的Node上启动运行，直到Pod实例的数量达到预定目标。这个过程完全是自动化的，无须人工干预。

Label Selector 在 Kubernetes 中的重要使用场景有以下几处：

1）kube-controller 进程通过资源对象RC 上定义的Label Selector 来筛选要监控的Pod 副本的数量，从而实现Pod 副本的数量始终符合预期设定的全自动控制流程。

2）kube-proxy 进程通过Service 的Label Selector 来选择对应的Pod ，自动建立起每个Service 到对应Pod 的请求转发路由表，从而实现Service 的智能负载均衡机制。

3）通过对某些Node 定义特定的Label ，并且在Pod 定义文件中使用NodeSelector 这种标签调度策略， kube-sheduler 进程可以实现Pod “定向调度”的特性。

使用 Label 可以给对象创建多组标签， Label 和 Label Selector 共同构成了Kubernetes系统中最核心的应用模型，使得被管理对象能够被精细地分组管理，同时实现了整个集群的高可用性。

Deployment：

Deployment 是 Kubernetes vl.2 引入的新概念，引入的目的是为了更好地解决Pod 的编排问题。为此， Deployment 在内部使用了Replica Set 来实现目的，我们可以把它看作 RC 的一次升级。

Deployment 相对于RC 的一个最大升级是我们可以随时知道当前 Pod “部署”的进度。实际上由于一个Pod 的创建、调度、绑定节点及在目标Node 上启动对应的容器这一完整过程需要一定的时间，所以我们期待系统启动 N 个Pod 副本的目标状态，实际上是一个连续变化“部署过程”导致的最终状态。

Deployment 的典型使用场景有以下几个：
。创建一个Deployment 对象来生成对应的Replica Set 并完成Pod 副本的创建过程
。检查 Deployment 的状态来看部署动作是否完成（ Pod 副本的数量是否达到预期的值）
。更新Deployment 以创建新的Pod （比如镜像升级）
。如果当前Deployment 不稳定，则回滚到一个早先的Deployment 版本
。暂停Deployment 以便于一次性修改多个PodTemplateSpec 的配置项，之后再恢复Deployment ，进行新的发布
。扩展Deployment 以应对高负载
。查看Deployment 的状态，以此作为发布是否成功的指标
。清理不再需要的旧版本ReplicaSets

Namespace：

Namespace(命名空间) 是Kubernetes 系统中的另一个非常重要的概念， Namespace 在很多情况下用于实现多租户的资源隔离。Namespace 通过将集群内部的资源对象“分配”到不同的Namespace 中，形成逻辑上分组的不同项目、小组或用户组，便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。

Kubemetes 集群在启动后，会创建一个名为“ default ”的Namespace ，通过 kubectl 可以查看到：
$ kubectl get namespaces

如果不特别指明Namespace ，则用户创建的Pod 、RC 、Service 都将被系统创建到这个默认的名为default 的Namespace 中。

Namespace定义 yaml 文件：

apiVersion: vl
kind: Namespace
metadata:
      name: development


Pod重启策略：
Always:当容器终止退出后，总是重启容器，默认策略
OnFailure:当容器异常退出(退出状态码非0)时，才重启容器
Never：当容器终止退出，从不重启容器

spec:
    containers:
    restartPolicy:Always/OnFailure/Never


Pod健康检查：

提供Probe机制，有以下两种类型：
1.livenessProbe:如果检查失败，将杀死容器，然后根据Pod的重启策略来决定是否重启
2.readinessProbe:如果检查失败，Kubernetes会把Pod从服务代理的分发后端剔除

Probe支持以下三种检查方法：
1.httpGet:发送HTTP请求，返回200--400范围状态码为成功
2.exec：执行Shell命令返回状态码是0为成功
3.tcpSocket：发起TCP Socket建立成功

spec:
    containers:
        livenessProbe:
            httpGet:
                path:/index.html
                port:80


Service 服务发现：

服务发现支持Service环境变量和DNS两种模式：

1.环境变量
当一个Pod运行到Node，kubelet会为每个容器添加一组环境变量，Pod容器中程序就可以使用这些环境变量发现Service。

环境变量名格式如下：
{SVCNAME}_SERVICE_HOST
{SVCNAME}_SERVICE_PORT
其中服务名和端口名为大写，连字符为下划线
注意：
1）Pod和Service的创建顺序是有要求的，Service必须在Pod创建之前被创建，否则环境变量不会设置到Pod中
2）Pod只能获取通Namespace中的Service环境变量

2.DNS
DNS服务监视kubernetes API，为每一个Service创建DNS记录
用于域名解析，这样Pod中就可以通过DNS域名获取Service的访问地址


数据卷 Volume：

1.本地数据卷
1).emptyDir
当Pod分配到Node时，首先创建一个空卷，并挂载到Pod的容器，Pod中的容器可以读取和写入卷中的文件。
当Pod从节点中删除emptyDir时，该数据也会被删除。

2).hostPath
一个hostPath卷挂载Node文件系统上的文件或目录到Pod中的容器


2.网络数据卷


nginx-nfs.yaml

apiVersion:extensions/v1beta1
kind:Deployment
metadata:
    name:nginx-deployment
spec:
    replicas:3
        template:
            metadata:
                labels:
                    app:nginx
            spec:
                containers:
                    - name:nginx
                    image:nginx:1.10
                    volumeMounts:
                        - name:wwwroot
                        mountPath:/var/www/html
                    ports:
                        - containerPort:80
                volume:
                    - name:wwwroot
                      nfs:
                        server:192.168.0.155
                        path:/opt/wwwroot