标签：扩容 选择 宕机 监控 strong 检测 自动 分配 中心
Kubernetes最初源于谷歌内部的Borg，提供了面向应用的容器集群部署和管理系统。Kubernetes的目标旨在消除编排物理/虚拟计算，网络和存储基础设施的负担，并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。Kubernetes 也提供稳定、兼容的基础（平台），用于构建定制化的workflows 和更高级的自动化任务。 Kubernetes 具备完善的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。 Kubernetes 还提供完善的管理工具，涵盖开发、部署测试、运维监控等各个环节。
Kubernetes作为云原生应用的基石，相当于一个云操作系统。
架构一
架构二
etcd保存了整个集群的状态；
apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
kubelet负责维护容器的生命周期，同时也负责Volume（CSI）和网络（CNI）的管理；
Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；
除了核心组件，还有一些推荐的Add-ons：(更新中)
Kubernetes是一个完备的分布式系统支撑平台。Kubernetes具有完备的集群管理能力，包括多层次的安全防护和准入机制/多租户应用支撑能力、透明的服务注册和服务发现机制、内建智能负载均衡器、强大的故障发现和自我修复功能、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制，以及多粒度的资源配额管理能力。同时kubernetes提供了完善的管理工具，这些工具覆盖了包括开发、测试部署、运维监控在内的各个环节；因此kubernetes是一个全新的基于容器技术的分布式架构解决方案，并且是一个一站式的完备的分布式系统开发和支撑平台
Service(服务)是分布式集群架构的核心，一个Server 对象拥有如下关键特征
(1) 拥有一个唯一指定的名字(比如mysql-server)
(2) 拥有一个虚拟IP (Cluster IP、Service IP或VIP)和端口号
(3) 能够提供某种远程服务能力
(4) 被映射到了提供这种服务能力的一组容器应用上
Service的服务进程目前都基于Socker通信方式对外提供服务，比如redis、memcache、MySQL、Web Server，或者是实现了某个具体业务的一个特定的TCP Server进程。虽然一个Service通常由多个相关的服务进程来提供服务，每个服务进程都有一个独立的Endpoint(IP+Port)访问点，但Kubernetes 能够让我们通过Service虚拟Cluster IP+Service Port连接到指定的Service上。有了Kubernetes内建的透明负载均衡和故障恢复机制，不管后端有多少服务进程，也不管某个服务进程是否会由于发生故障而重新部署到其他机器，都不会影响到我们对服务的正常调用。更重要的是这个Service本身一旦创建就不再变化，这意味着Kubernetes集群中，再也不用为了服务的IP地址变来变去的问题而烦恼。
Pod概念
Pod运行在一个我们称之为节点Node的环境中，可以是私有云也可以是公有云的虚拟机或者物理机，通常在一个节点上运行几百个Pod;其次，每个Pod里运行着一个特殊的被称之为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此他们之间的通讯和数据交换更为高效。在设计时我们可以充分利用这一特征将一组密切相关的服务进程放入同一个Pod中。
并不是每个Pod和它里面运行的容器都能映射到一个Service 上，只有那些提供服务(无论是对内还是对外)的一组Pod才会被映射成一个服务。
Service 和Pod如何关联
容器提供了强大的隔离功能，所以有必要把为Service提供服务的这组进程放入到容器中隔离。Kubernetes设计了Pod对象，将每个服务进程包装到相应的Pod中，使其成为Pod中运行的一个容器Container。为了建立Service 和Pod间的关联关系，Kubernetes 首先给每个Pod填上了一个标签Label,给运行MySQL的Pod贴上name=mysql标签，给运行PHP的Pod贴上name=php标签，然后给相应的Service定义标签选择器Label Selector，比如MySQL Service的标签选择器的选择条件为name=mysql，意为该Service 要作用于所有包含name=mysql Label的Pod上。这样就巧妙的解决了Service和Pod关联问题
RC介绍
在Kubernetes集群中，你只需要为需要扩容的Service关联的Pod创建一个RC Replication Controller则该Service的扩容以至于后来的Service升级等头疼问题都可以迎刃而解。
定义一个RC文件包括以下3个关键点
(1) 目标Pod的定义
(2) 目标Pod需要运行的副本数量(Replicas)
(3) 要监控的目标Pod的标签(Label)
在创建好RC系统自动创建好Pod后，kubernetes会通过RC中定义的Label筛选出对应的Pod实力并实时监控其状态和数量，如果实例数量少于定义的副本数量Replicas,则会用RC中定义的Pod模板来创建一个新的Pod，然后将此Pod调度到合适的Node上运行，直到Pod实例的数量达到预定目标。这个过程完全是自动化的，无需人干预。只要修改RC中的副本数量即可。
Master介绍
Kubernetes 里的Master指的是集群控制节点，每个Kubernetes集群里需要有一个Master节点来负责整个集群的管理和控制，基本上Kubernetes所有的控制命令都发给它，它负责具体的执行过程，我们后面执行的所有命令基本上都是在Master节点上运行的。如果Master宕机或不可用，那么集群内容器的管理都将失效
Master节点上运行着以下一组关键进程：
Kubernetes API Server (kube-apiserver)：提供了HTTP Rest接口的关键服务进程，是Kubernetes里所有资源的增、删、改、查等操作的唯一入口，也是集群控制的入口进程
Kubernetes Controller Manager (kube-controller-manager):Kubernetes里所有的资源对象的自动化控制中心
Kubernetes Scheduler (kube-scheduler)：负责资源调度(Pod调度)的进程
另外在Master节点上还需要启动一个etcd服务,因为Kubernetes里的所有资源对象的数据全部是保存在etcd中
Node介绍
除了Master，集群中其他机器被称为Node节点，每个Node都会被Master分配一些工作负载Docker容器，当某个Node宕机时，其上的工作负载会被Master自动转移到其他节点上去。
每个Node节点上都运行着以下一组关键进程。
kubelet：负责Pod对应容器的创建、停止等任务，同时与Master节点密切协作，实现集群管理的基本功能
kube-proxy：实现Kubernetes Service的通信与负载均衡机制的重要组件。
Docker Engine(Docker)：Docker引擎，负责本机的容器创建和管理工作。
在集群管理方面，Kubernets将集群中的机器划分为一个Master节点和一群工作节点(Node),其中，在Master节点上运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、Pod调度、弹性收缩、安全控制、系统监控和纠错等管理功能，并且都是全自动完成的。Node作为集群中的工作节点，运行真正的应用程序，在Node上Kubernetes管理的最小运行单元是Pod。Node上运行着Kubernetes的kubelet、kube-proxy服务进程，这些服务进程负责Pod创建、启动、监控、重启、销毁、以及实现软件模式的负载均衡
标签：扩容 选择 宕机 监控 strong 检测 自动 分配 中心
原文地址：https://www.cnblogs.com/FireLL/p/12082990.html
