Docker 容器云 K8S

云计算平台

云计算

云计算是一种资源的服务模式，该模式可以实现随时随地、便捷按需地从可配置计算资源共享池中获取所需的资源（网络，服务器，存储，应用及服务），资源能够快速供应并且释放
经典的云计算架构包含以下三层服务：

1. IaaS Infrastructure as a Service 基础设施即服务
2. PaaS Platform as a Service 平台即服务
3. SaaS Software as a Service 软件即服务

基础设施即服务

IaaS为基础设施运维人员服务
提供计算，存储，网络及其他基础资源
云平台使用者可以在上面部署和运行包括操作系统和应用程序在内的任意软件，无须为基础平台的管理分心

平台即服务

PaaS为开发人员服务
提供支撑应用运行所需的软件运行时环境、相关工具与服务（比如数据库服务，日志服务，监控服务等）
让应用开发者可以专注于核心业务的开发

软件即服务

SaaS为一般用户服务
提供了一套完整的软件系统
让一般用户无需关注技术细节，只需要通过浏览器、应用客户端就能使用部署在云上的应用服务

容器 & Docker

不论是IaaS还是PaaS都有各自的应用场景，但是又有着诸多的缺陷
IaaS ： 主要是以虚拟机为最小粒度的资源调度单位，资源利用率低，调度分发缓慢，软件栈环境不统一等一系列问题。
PaaS： 在IaaS的基础上发展而来，采用了容器的方式解决资源利用率的问题，但是PaaS通常在应用架构选择、支持的软件环境服务方面有较大的限制。应用与平台无法解耦，应用运行时环境局限性强，运维人员控制力下降等问题。

容器

以Docker为代表的容器技术的生态系统自下而上分别覆盖了IaaS和PaaS涉及的各类问题，包括资源调度，编排，部署，监控，配置管理，存储网络管理，安全，容器化应用支撑平台等。

容器技术带来了哪些

1. 持续化部署与测试
2. 跨云平台支持
3. 环境标准化和版本控制
4. 高资源利用率与隔离
5. 容器跨平台性与镜像
6. 易于理解且易用
7. 应用镜像仓库

容器云

容器云是以容器为资源分割和调度的基本单位，封装整个软件运行时环境，为开发者和系统管理员提供用于构建、发布和运行分布式应用的平台。
容器云中会按功能或者依赖敏感性划分成组，不同容器之间完全隔离，组内容器允许一定程度共享，容器间的关系不再简单的依靠docker link 这类原生命令进行组织，而往往借助全局网络管理组件进行统一治理。容器云用户也不需要直接面对dockerAPI，而是借助某种控制器来完成用户操作到Docker容器之间的调用转译，从而保证底层容器操作对旁路控制而非直接侵入Docker体系。

K8S

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

• 拥有一个唯一指定的名字
• 拥有一个虚拟IP（Cluster IP、Service IP、或VIP）和端口号
• 能够提供某种远程服务能力
• 被映射到了提供这种服务能力的一组容器应用上

Kubernetes内建的透明负载均衡和故障恢复机制，不管后端有多少服务进程，也不管某个服务进程是否会由于发生故障而重新部署到其他机器，都不会影响我们对服务的正常调用，更重要的是这个Service本身一旦创建就不会发生变化，意味着在Kubernetes集群中，服务的IP地址不再会发生变化！

容器提供了强大的隔离功能，所以有必要把为Service提供服务的这组进程放入容器中进行隔离。为此，Kubernetes设计了Pod对象，将每个服务进程包装到相对应的Pod中，使其成为Pod中运行的一个容器。为了建立Service与Pod间的关联管理，Kubernetes给每个Pod贴上一个标签Label

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

k8s的核心概念

Master

k8s集群的管理节点，负责管理集群，提供集群的资源数据访问入口。

• 拥有Etcd存储服务（可选）
• 运行API Sever进程，Controller Manager进程，Scheduler服务进程。
• 关联工作节点Node

k8s的API server是k8s里的所有资源的操作的唯一入口，也是集群控制的入口进程
k8s的Controller Manager是k8s所有资源对象的自动化控制中心
k8s的Scheduler 是负责资源调度（Pod调度）的进程

Node

Node是k8s集群中运行Pod的服务节点。
Node是k8s集群操作的单元，用来承载被分配Pod的运行，是Pod的宿主机。
关联Master管理节点，拥有名称和IP，系统资源信息。
每个Node节点都运行着以下关键进程

• kubelet：负责对Pod的容器的创建、启停等任务
• kube-proxy：实现kubernetes service的通信与负载均衡机制的重要组件
• Docker Engine(Docker)： Docker引擎，负责本机容器的创建和管理工作

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

Pod

Pod意思是豆荚，是k8s中能够被创建、调度和管理的最小单元。Pod运行在Node节点上，是若干个相关容器的组合。
Pod内的容器运行在同一台宿主机，容器间共享network namespace，并且通过volume机制共享一部分存储。
Pod一旦被创建就会被k8sMaster调度到某个具体的Node上进行绑定，随后会被k8s kubelet进程实例化成一组相关的Docker容器并且启动起来。当Pod里的某个容器停止是，k8s会自动检测到这个问题并且重启这个Pod（Pod里的所有容器），如果Pod所在的Node宕机，会将所有Pod重新调度到其他节点上。

Replication Controller（RC）

RC是用来管理Pod副本的，保证集群中存在指定数量的Pod副本。集群中副本的数量大于指定数量，则会停止指定数量之外的多于容器，如果集群中副本的数量小于指定数量，则保证数量不变。RC是实现弹性伸缩、动态扩容和滚动升级的核心。

Service

Service定义了Pod的逻辑集合和访问该集合的策略。
Service提供了一个统一的服务访问入口以及服务代理和发现机制，关联多个相同Label的Pod，用户不需要了解Pod是怎么运行的
外部系统访问Service的问题

首先需要弄明白Kubernetes的三种IP这个问题

Node IP：Node节点的IP地址

Pod IP： Pod的IP地址

Cluster IP：Service的IP地址

首先,Node IP是Kubernetes集群中节点的物理网卡IP地址，所有属于这个网络的服务器之间都能通过这个网络直接通信。这也表明Kubernetes集群之外的节点访问Kubernetes集群之内的某个节点或者TCP/IP服务的时候，必须通过Node IP进行通信

其次，Pod IP是每个Pod的IP地址，他是Docker Engine根据docker0网桥的IP地址段进行分配的，通常是一个虚拟的二层网络。

最后Cluster IP是一个虚拟的IP，但更像是一个伪造的IP网络，原因有以下几点

Cluster IP仅仅作用于Kubernetes Service这个对象，并由Kubernetes管理和分配P地址
Cluster IP无法被ping，他没有一个“实体网络对象”来响应
Cluster IP只能结合Service Port组成一个具体的通信端口，单独的Cluster IP不具备通信的基础，并且他们属于Kubernetes集群这样一个封闭的空间。
Kubernetes集群之内，Node IP网、Pod IP网于Cluster IP网之间的通信，采用的是Kubernetes自己设计的一种编程方式的特殊路由规则。

Label

Kubernetes中的任意API对象都是通过Label进行标识，Label的实质是一系列的Key/Value键值对，其中key于value由用户自己指定。Label可以附加在各种资源对象上，如Node、Pod、Service、RC等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上去。Label是Replication Controller和Service运行的基础，二者通过Label来进行关联Node上运行的Pod。

我们可以通过给指定的资源对象捆绑一个或者多个不同的Label来实现多维度的资源分组管理功能，以便于灵活、方便的进行资源分配、调度、配置等管理工作。

一些常用的Label如下：

版本标签：“release”:“stable”,“release”:“canary”…
环境标签：“environment”:“dev”,“environment”:“qa”,“environment”:“production”
架构标签：“tier”:“frontend”,“tier”:“backend”,“tier”:“middleware”
分区标签：“partition”:“customerA”,“partition”:“customerB”
质量管控标签：“track”:“daily”,“track”:“weekly”
　　Label相当于我们熟悉的标签，给某个资源对象定义一个Label就相当于给它大了一个标签，随后可以通过Label Selector（标签选择器）查询和筛选拥有某些Label的资源对象，Kubernetes通过这种方式实现了类似SQL的简单又通用的对象查询机制。
　　Label Selector在Kubernetes中重要使用场景如下:

kube-Controller进程通过资源对象RC上定义Label Selector来筛选要监控的Pod副本的数量，从而实现副本数量始终符合预期设定的全自动控制流程
　　kube-proxy进程通过Service的Label Selector来选择对应的Pod，自动建立起每个Service岛对应Pod的请求转发路由表，从而实现Service的智能负载均衡
　　通过对某些Node定义特定的Label，并且在Pod定义文件中使用Nodeselector这种标签调度策略，kuber-scheduler进程可以实现Pod”定向调度“的特性