【本文正在参与炫"库"行动-人大金仓有奖征文】
活动链接：
CSDN
- 1k8s基本概念
Kubernetes（简称k8s）是Google在2014年6月开源的一个容器集群管理系统，使用Go语言开发，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效,Kubernetes提供了资源调度、部署管理、服务发现、扩容缩容、监控，维护等一整套功能。，努力成为跨主机集群的自动部署、扩展以及运行应用程序容器的平台。 它支持一系列容器工具, 包括Docker等。
kubernetes特点:
可移植: 支持公有云，私有云，混合云，多重云（multi-cloud）
可扩展: 模块化, 插件化, 可挂载, 可组合
自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展
Kubernetes一个核心的特点就是自动化，能够自主的管理容器来保证云平台中的容器按照用户的期望状态运行着（比如用户想让apache一直运行，用户不需要关心怎么去做，Kubernetes会自动去监控，然后去重启，新建，总之，让apache一直提供服务），管理员可以加载一个微型服务，让规划器来找到合适的位置，同时，Kubernetes也系统提升工具以及人性化方面，让用户能够方便的部署自己的应用（就像canary deployments）。
现在Kubernetes着重于不间断的服务状态（比如web服务器或者缓存服务器）和原生云平台应用（Nosql）,在不久的将来会支持各种生产云平台中的各种服务，例如，分批，工作流，以及传统数据库。
kubenetes(k8s):容器编排调度引擎: 大体功能为简化应用部署、提高硬件资源利用率、健康检查和自修复、自动扩容缩容、服务发现和负载均衡，简而言之就是对docker做集群管理。
- 2各组件基本介绍：
资源对象：
Node、Pod、Replication Controller、Service
Master：集群控制管理节点，所有的命令都经由master处理。包括kube-apiserver(对资源 增删改查的唯一接口)、kube-controller-manager（资源对象的自动化控制中心）、kube-scheduler（资源对象的资源调度进程）。
Node:工作负载节点，挂了之后，其工作负载会被自动转移到其他节点。Node可动态添加到k8s进程中。
kubelet:每个Node上面的代理，管理本机的容器。
Pod:一个根容器加多个业务容器，集群内任意两个Pod之间可以根据PodIP(Pod的唯一IP地址)进行通信。
Label:一个key-value键值对，可以附到各种资源对象上。
RC:Replication Controller 复制控制器，每个Pod都有一定数量的副本，副本数小于期望时，用于新的创建Pod的模板template.通过改变RC的副本数量，可以实现Pod的扩容或者缩容，通过改变RC的模板的镜像版本，可以实现Pod的滚动升级。
Volume:Pod中能够被多个容器访问的共享目录。定义在Pod里面。
etcd: 一个key-value的存储仓库，用于配置共享和服务发现。其存储分为内部存储与持久化存储，采用raft算法，强一致算法。
flannel:虚拟二次网络。
kube-proxy:监控Pod状态，立即更新iptables/ipvs规则。类似路由。
Service:服务抽象，可以对POD实现转发机制。
Deployment:无状态应用部署
StatefulSet:有状态应用部署
DaemonSet:确保所有Node运行用一个Pod
Namespace:命名对象，将对象进行逻辑隔离。
大体执行流程：
用户执行kubectl/userClient向apiserver发起一个命令，经过认证授权后，经过scheduler的各种策略，得到一个目标node，然后告诉apiserver，apiserver 会请求相关node的kubelet，通过kubelet把pod运行起来，apiserver还会将pod的信息保存在etcd；
pod运行起来后，controllermanager就会负责管理pod的状态，如，若pod挂了，controllermanager就会重新创建一个一样的pod，或者像扩缩容等；pod有一个独立的ip地址，但pod的IP是易变的，如异常重启，或服务升级的时候，IP都会变，这就有了service；
完成service工作的具体模块是kube-proxy；在每个node上都会有一个kube-proxy，在任何一个节点上访问一个service的虚拟ip，都可以访问到pod；service的IP可以在集群内部访问到，在集群外呢？service可以把服务端口暴露在当前的node上，外面的请求直接访问到node上的端口就可以访问到service了。
架构图：
- 3各组件详细介绍：
Master:
k8s的主控组件，对应的对象是node。
k8s的master节点上有三个进程，它们都是以docker的形式存在的。我们在k8s的master节点看docker ps 就可以看到这几个进程：kube-apiserver、kube-controller、kube-scheduler。
其中的 apiserver 是提供 k8s 的 rest api 服务的进程。当然它也包括了 restapi 的权限认证机制。 k8s 的 apiserver 提供了三种权限认证机制：
- https
- http + token
- http + base（username + password）
一个k8s集群只有一个master节点（也可以配置多个），所以 master 节点的高可用性是一个问题，一旦 master 节点挂了，整个集群也就挂了。
如何实现master节点的高可用？
master节点上的几个服务kube-apiserver、kube-scheduler和kube-controller-manager都是单点的而且都位于同一个节点上，一旦master节点宕机，虽然不应答当前正在运行的应用，将导致kubernetes集群无法变更。
Pod:
在Kubernetes集群中，Pod是所有业务类型的基础，也是K8S管理的最小单位级，它是一个或多个容器的组合。这些容器共享存储、网络和命名空间，以及如何运行的规范。在Pod中，所有容器都被同一安排和调度，并运行在共享的上下文中。对于具体应用而言，Pod是它们的逻辑主机，Pod包含业务相关的多个应用容器。
Pod有两个必须知道的特点:
网络:每一个Pod都会被指派一个唯一的Ip地址，在Pod中的每一个容器共享网络命名空间，包括Ip地址和网络端口。在同一个Pod中的容器可以同locahost进行互相通信。当Pod中的容器需要与Pod外的实体进行通信时，则需要通过端口等共享的网络资源。
存储:Pod能够被指定共享存储卷的集合，在Pod中所有的容器能够访问共享存储卷，允许这些容器共享数据。存储卷也允许在一个Pod持久化数据，以防止其中的容器需要被重启。
Pod的工作方式:
Pod模版:
K8s一般不直接创建Pod。 而是通过控制器和模版配置来管理和调度
Pod重启:
在Pod中的容器可能会由于异常等原因导致其终止退出，Kubernetes提供了重启策略以重启容器。重启策略对同一个Pod的所有容器起作用，容器的重启由Node上的kubelet执行。Pod支持三种重启策略，在配置文件中通过restartPolicy字段设置重启策略：
Always：只要退出就会重启。
OnFailure：只有在失败退出（exit code不等于0）时，才会重启。
Never：只要退出，就不再重启注意，这里的重启是指在Pod的宿主Node上进行本地重启，而不是调度到其它Node上。
资源限制:
Kubernetes通过cgroups限制容器的CPU和内存等计算资源，包括requests（请求，调度器保证调度到资源充足的Node上）和limits（上限）等：
健康检查：
在Pod部署到Kubernetes集群中以后，为了确保Pod处于健康正常的运行状态，Kubernetes提供了两种探针，用于检测容器的状态：
Liveness Probe ：检查容器是否处于运行状态。如果检测失败，kubelet将会杀掉掉容器，并根据重启策略进行下一步的操作。如果容器没有提供Liveness Probe，则默认状态为Success；
ReadinessProbe ：检查容器是否已经处于可接受服务请求的状态。如果Readiness Probe失败，端点控制器将会从服务端点（与Pod匹配的）中移除容器的IP地址。Readiness的默认值为Failure，如果一个容器未提供Readiness，则默认是Success。
kubelet在容器上周期性的执行探针以检测容器的健康状态，kubelet通过调用被容器实现的处理器来实现检测，在Kubernetes中有三类处理器：
ExecAction ：在容器中执行一个指定的命令。如果命令的退出状态为0，则判断认为是成功的；
TCPSocketAction ：在容器IP地址的特定端口上执行一个TCP检查，如果端口处于打开状态，则视为成功；
HTTPGetAcction ：在容器IP地址的特定端口和路径上执行一个HTTP Get请求使用container的IP地址和指定的端口以及请求的路径作为url，用户可以通过host参数设置请求的地址，通过scheme参数设置协议类型(HTTP、HTTPS)如果其响应代码在200~400之间，设为成功。
健康检测的结果为下面三种情况：
Success ：表示容器通过检测
Failure ：表示容器没有通过检测
Unknown ：表示容器容器失败
初始化容器:
在开发一个程序时，通常初化代码与主体业务代码放置在同一个程序中。为什么kubernetes提供初始化容器这种功能，将初始化工作从普通容器中隔离出来？这种特性有什么用呢？初始化容器与普通容器有各自独立的image，本质上是将初始化逻辑与主体业务逻辑分离并放置在不同的image中，以下是初始化容器的主要用处：
1.初始化容器可以包含不能随普通容器一起发布出去的敏感信息。
2.初始化容器可以包含用户自定义的代码、工具，如sed、awk、python等方便完成初始化、设置工作。
3.因为初始化逻辑与主体业务逻辑分布在不同的image中，因此image构建者与主体业务逻辑开发者可以各自独立的工作。
4.初始化容器使用Linux namespace，不同于普通应用容器，具有不同的文件系统视图，并且对于低层的操作系统有更大的访问权限。
5.当应用启动的前置条件不具备时，初始化容器可以阻止普通应用容器启动，避免在条件不具备时反复启动注定会失败的容器而浪费系统资源。
POD调度:
节点选择:
nodeSelector是目前最为简单的一种pod运行时调度限制，Pod.spec.nodeSelector通过kubernetes的label-selector机制选择节点，由调度器调度策略匹配label，而后调度pod到目标节点，该匹配规则属于强制约束。
亲和性（Affinity）与非亲和性（anti-affinity）:
1.requiredDuringSchedulingIgnoredDuringExecution:可认为一种强制限制，如果 Node 的标签发生了变化导致其没有符合 Pod 的调度要求节点，那么pod调度就会失败。
2.preferredDuringSchedulingIgnoredDuringExecution:软限或偏好，同样如果 Node 的标签发生了变化导致其不再符合 pod 的调度要求，pod 依然会调度运行。
pod亲和性（Inter-pod affinity）与反亲和性（anti-affinity）:
podAffinity用于调度pod可以和哪些pod部署在同一拓扑结构之下。而podAntiAffinity相反，其用于规定pod不可以和哪些pod部署在同一拓扑结构下。通过pod affinity与anti-affinity来解决pod和pod之间的关系。
污点（Taints）与容忍（tolerations）:
对于Node affinity，无论是强制约束（hard）或偏好（preference）方式，都是调度pod到预期节点上，而Taints恰好与之相反，如果一个节点标记为 Taints ，除非 Pod也被标识为可以耐受污点节点，否则该Taints节点不会被调度pod。Taints与tolerations当前处于beta阶段，Taints节点应用场景比如用户希望把Kubernetes Master节点保留给 Kubernetes 系统组件使用，或者把一组具有特殊资源预留给某些 pod。pod不会再被调度到taint标记过的节点。
Kubelet：
kubelet处理着master和在其上运行的节点之间的所有通信。它以manifest的形式接收来自主设备的命令，manifest定义着工作负载和操作参数。它与负责创建、启动和监视pod的容器运行时进行接合。
kubelet还会周期性地对配置的活跃度探针和准备情况进行检查。它会不断监视pod的状态，并在出现问题时启动新实例。kubelet还有一个内部HTTP服务器，在端口10255上显示一个只读视图。除此之外，在/healthz上还有一个健康检查端点，以及一些其他状态端点。例如，我们可以在/pods获取正在运行的pod的列表。我们还可以在/spec获取kubelet正在运行的机器的详情。
常用命令：
查看所有 pod 列表, -n 后跟 namespace, 查看指定的命名空间
kubectl get pod
#查看pod列表
kubectl get pod -n kube
#查看default命令空间下的pod列表
kubectl get pod -o wide
查看 RC 和 service 列表， -o wide 查看详细信息
kubectl get rc,svc
查看rc和svc列表
kubectl get pod,svc -o wide
kubectl get pod
显示 Node 的详细信息
kubectl describe node 192.168.0.212
显示 Pod 的详细信息, 特别是查看 pod 无法创建的时候的日志
kubectl describe pod
eg:
kubectl describe pod xxx
根据 yaml 创建资源, apply 可以重复执行，create 不行
kubectl create -f pod.yaml
kubectl apply -f pod.yaml
基于 pod.yaml 定义的名称删除 pod
kubectl delete -f pod.yaml
删除所有包含某个 label 的pod 和 service
kubectl delete pod,svc -l name=
删除所有 Pod
kubectl delete pod --all
查看 endpoint 列表
kubectl get endpoints
执行 pod 的 date 命令
kubectl exec
kubectl exec
kubectl exec
通过bash获得 pod 中某个容器的TTY，相当于登录容器
kubectl exec -it
eg:
kubectl exec -it redis-master-cln81 -- bash
查看容器的日志
kubectl logs
kubectl logs -f
# 实时查看日志
kubectl log
# 若 pod 只有一个容器，可以不加 -c
kubectl explain pod
#查看注释
kubectl explain pod.apiVersion
kube-proxy：
kube-proxy组件在每个节点上运行，负责代理UDP、TCP和SCTP数据包（它不了解HTTP）。它负责维护主机上的网络规则，并处理pod、主机和外部世界之间的数据包传输。它就像是节点上运行着的pod的网络代理和负载均衡器一样，通过在iptables使用NAT实现东/西负载均衡。
kube-proxy过程位于连接到Kubernetes的网络和在该特定节点上运行的pod之间。它本质上是Kubernetes的核心网络组件，负责确保跨集群的所有元素有效地进行通信。当用户创建Kubernetes服务对象时，kube-proxy实例会负责将该对象转换为位于worker节点的、本地iptables规则集上的有意义的规则。iptables用于将分配给服务对象的虚拟IP转换为服务映射的所有pod IP。
容器运行时：容器运行时负责从公有或私有镜像仓库中拉取镜像，并根据这些镜像运行容器。当下最流行的容器引擎无疑是Docker，不过Kubernetes还支持诸如rkt、runc等的其他容器运行时。正如我们在上文中提到过的，kubelet会直接与容器运行时交互，以启动、停止或删除容器。
cAdvisor：cAdvisor是一个开源代理，它能够监视资源使用情况并分析容器的性能。 cAdvisor最初由谷歌创建，现在已与kubelet集成。
位于每个节点上的cAdvisor实例，会收集、聚合、处理和导出所有正在运行的容器的指标，如CPU、内存、文件和网络使用情况等。所有数据都将发送到调度程序，以确保调度程序了解节点内部的性能和资源使用情况。这些信息会被用于执行各种编排任务，如调度、水平pod扩展、管理容器资源限制等。
RC:
Replication Controller (简称RC),RC是Kubernetes系统中的核心概念之一,简单来说,它定义了一个期望的场景,即声明某种Pod的副本数量在任意时刻都符合某个预期值
RC定义了如下
1.Pod期待的副本数(replicas)
2.用于筛选目标Pod的Label Seletcor(标签选择器)
3.当Pod的副本小于预期(replicas)时，用于创建新Pod的Pod模板(template)
RC主要功能
确保Pod数量: 它会确保Kubernetes中有指定数量的Pod在运行，如果少于指定数量的Pod，RC就会创建新的，反之会删除多余的，保证Pod的副本数量不变
确保Pod健康: 当Pod不健康，RC会杀死不健康的Pod，重新创建新的
弹性伸缩: 在业务高峰或者低峰的时候，可以用RC来动态调整Pod数量来提供资源的利用率吧，当然也可以使用HPA来实现
滚动升级: 滚动升级是一种平滑的升级方式，通过逐步替换的策略，保证整体系统的稳定性
Volume:
容器和 Pod 是短暂的。其含义是它们的生命周期可能很短，会被频繁地销毁和创建。容器销毁时，保存在容器内部文件系统中的数据都会被清除。为了持久化保存容器的数据，可以使用 Kubernetes Volume。Volume 的生命周期独立于容器，Pod 中的容器可能被销毁和重建，但 Volume 会被保留。本质上，Kubernetes Volume 是一个目录，这一点与 Docker Volume 类似。当 Volume 被 mount 到 Pod，Pod 中的所有容器都可以访问这个 Volume。Kubernetes Volume 也支持多种 backend 类型，包括 emptyDir、hostPath、GCE Persistent Disk、AWS Elastic Block Store、NFS、Ceph 等。Volume 提供了对各种 backend 的抽象，容器在使用 Volume 读写数据的时候不需要关心数据到底是存放在本地节点的文件系统中呢还是云硬盘上。对它来说，所有类型的 Volume 都只是一个目录。
Volume之emptyDir
emptyDir 是最基础的 Volume 类型。正如其名字所示，一个 emptyDir Volume 是 Host 上的一个空目录。
emptyDir Volume 对于容器来说是持久的，对于 Pod 则不是。当 Pod 从节点删除时，Volume 的内容也会被删除。但如果只是容器被销毁而 Pod 还在，则 Volume 不受影响。
也就是说：emptyDir Volume 的生命周期与 Pod 一致。
Pod 中的所有容器都可以共享 Volume，它们可以指定各自的 mount 路径。
Volume之hostPath
hostPath Volume 的作用是将 Docker Host 文件系统中已经存在的目录 mount 给 Pod 的容器。大部分应用都不会使用 hostPath Volume，因为这实际上增加了 Pod 与节点的耦合，限制了 Pod 的使用。不过那些需要访问 Kubernetes 或 Docker 内部数据（配置文件和二进制库）的应用则需要使用 hostPath。
Etcd:
Etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现，它通过Raft一致性算法处理日志复制以保证强一致性，我们可以理解它为一个高可用强一致性的服务发现存储仓库。在kubernetes集群中，etcd主要用于配置共享和服务发现Etcd主要解决的是分布式系统中数据一致性的问题，而分布式系统中的数据分为控制数据和应用数据，etcd处理的数据类型为控制数据，对于很少量的应用数据也可以进行处理。
Etcd和Zookeeper的比较
Zookeeper有如下缺点
1.复杂。ZooKeeper的部署维护复杂，管理员需要掌握一系列的知识和技能；而Paxos强一致性算法也是素来以复杂难懂而闻名于世（ETCD使用[Raft]协议， ZK使用ZAB，类PAXOS协议）；另外，ZooKeeper的使用也比较复杂，需要安装客户端，官方只提供了Java和C两种语言的接口。
2.Java编写。这里不是对Java有偏见，而是Java本身就偏向于重型应用，它会引入大量的依赖。而运维人员则普遍希望保持强一致、高可用的机器集群尽可能简单，维护起来也不易出错。
3.发展缓慢。Apache基金会项目特有的“Apache Way”在开源界饱受争议，其中一大原因就是由于基金会庞大的结构以及松散的管理导致项目发展缓慢。
相较之下，Etcd
1.简单。使用Go语言编写部署简单；使用HTTP作为接口使用简单；使用Raft算法保证强一致性让用户易于理解。
2.数据持久化。etcd默认数据一更新就进行持久化。
3.安全。etcd支持SSL客户端安全认证。
流程分析：
通常一个用户的请求发送过来，会经过HTTP Server转发给Store进行具体的事务处理，如果涉及到节点的修改，则需要交给Raft模块进行状态的变更，日志的记录。
然后再同步给别的etcd节点确认数据提交，最后进行数据提交，再次同步。
工作原理
Etcd使用Raft协议来维护集群内各个节点状态的一致性。简单说，ETCD集群是一个分布式系统，由多个节点相互通信构成整体对外服务，每个节点都存储了完整的数据，并且通过Raft协议保证每个节点维护的数据是一致的。
Etcd主要分为四个部分
HTTP Server： 用于处理用户发送的API请求以及其他etcd节点的同步与心跳信息请求
Store: 用于处理 etcd 支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等，是 etcd 对用户提供的大多数 API 功能的具体实现。
Raft： Raft 强一致性算法的具体实现，是 etcd 的核心。
WAL：Write Ahead Log（预写式日志/日志先行），是 etcd 的数据存储方式，也是一种实现事务日志的标准方法。etcd通过 WAL 进行持久化存储，所有的数据提交前都会事先记录日志。Snapshot 是为了防止数据过多而进行的状态快照；Entry 表示存储的具体日志内容。
Etcd集群中的术语
Raft: etcd所采用的保证分布式系统强一致的算法
Node: 一个Raft状态机实例
Member: 一个etcd实例,管理一个Node，可以为客户端请求提供服务
Cluster: 多个Member构成的可以协同工作的etcd集群
Peer: 同一个集群中，其他Member的称呼
Client: 向etcd集群发送HTTP请求的客户端
WAL: 预写日志，是etcd用于持久化存储的日志格式
Snapshot: etcd防止WAL文件过多而设置的快照，存储etcd数据状态
Proxy: etcd的一种模式，可以为etcd提供反向代理服务
Leader: Raft算法中通过竞选而产生的处理所有数据提交的节点
Follower: Raft算法中竞选失败的节点，作为从属节点，为算法提供强一致性保证
Candidate: Follower超过一定时间接收不到Leader节点的心跳的时候，会转变为Candidate(候选者)开始Leader竞选
Term: 某个节点称为Leader到下一次竞选开始的时间周期,称为Term(任界，任期)
Index: 数据项编号, Raft中通过Term和Index来定位数据
Flannel
是一种 CNI 解决方案，也可以为 Dokcer 提供服务，对 k8s 而言，是一个网络插件。实现了 CNI 的网络控制平面软件属于 coreOS 的子项目
通过配置主机路由或者 overlay，避免对物理路由器进行配置VxLANUDPHost-GW和 k8s 集成时，运行在 work node 上面，监听 k8s master 的状态，共用 k8s 的控制节点的 etcd 作为自己的数据库。
- 4各组件高可用策略简介：
多master高可用：
Kubernetes通过Keepalived + Haproxy实现多个Master的高可用部署，实际上Kubernetes的多个Master是没有主从的，都可以提供一致性服务。Keepalived + Haproxy实际上就是提供了一个简单的负载均衡方式。需要在master节点手动安装keepalived, haproxy。需要将HAProxy默认的配置文件balance从source修改为roundrobin方式。haproxy的配置文件haproxy.cfg默认路径是/etc/haproxy/haproxy.cfg。修改keepalived的配置文件，配置正确的VIP。keepalived的配置文件keepalived.conf的默认路径是/etc/keepalived/keepalived.conf。
priority决定哪个Master是主，哪个Master是次。数字大的是主，数字小的是次。数字越大优先级越高。virtual_router_id决定当前VIP的路由号，实际上VIP提供了一个虚拟的路由功能，该VIP在同一个子网内必须是唯一。virtual_ipaddress提供的就是VIP的地址，该地址在子网内必须是空闲未必分配的。state 决定初始化时节点的状态, 建议 priority 最高的节点设置为 MASTER。
本质上就是多个Master通过负载均衡方式同时提供服务；
etcd高可用
etcd的高可用基本有三种思路：
一是使用独立的etcd集群，使用3台或者5台服务器只运行etcd，独立维护和升级。甚至可以使用CoreOS的update-engine和locksmith，让服务器完全自主的完成升级。这个etcd集群将作为基石用于构建整个集群。 采用这项策略的主要动机是etcd集群的节点增减都需要显式的通知集群，保证etcd集群节点稳定可以更方便的用程序完成集群滚动升级，减轻维护负担。
二是在Kubernetes Master上用static pod的形式来运行etcd，并将多台Kubernetes Master上的etcd组成集群。 在这一模式下，各个服务器的etcd实例被注册进了Kubernetes当中，虽然无法直接使用kubectl来管理这部分实例，但是监控以及日志搜集组件均可正常工作。在这一模式运行下的etcd可管理性更强。
三是使用CoreOS提出的self-hosted etcd方案，将本应在底层为Kubernetes提供服务的etcd运行在Kubernetes之上。 实现Kubernetes对自身依赖组件的管理。在这一模式下的etcd集群可以直接使用etcd-operator来自动化运维，最符合Kubernetes的使用习惯。
预算充足但保守的项目选方案一， 想一步到位并愿意承担一定风险的项目选方案三。折中一点选方案二。
kube-apiserver高可用
apiserver的高可用也有三种基本思路：
一是使用外部负载均衡器，不管是使用公有云提供的负载均衡器服务或是在私有云中使用LVS或者HaProxy自建负载均衡器都可以归到这一类。 负载均衡器是非常成熟的方案，在这里略过不做过多介绍。如何保证负载均衡器的高可用，则是选择这一方案需要考虑的新问题。
二是在网络层做负载均衡。比如在Master节点上用BGP做ECMP，或者在Node节点上用iptables做NAT都可以实现。采用这一方案不需要额外的外部服务，但是对网络配置有一定的要求。
三是在Node节点上使用反向代理对多个Master做负载均衡。这一方案同样不需要依赖外部的组件，但是当Master节点有增减时，如何动态配置Node节点上的负载均衡器成为了另外一个需要解决的问题。
从目前各个集群管理工具的选择来看，这三种模式都有被使用，目前还没有明确的推荐方案产生。建议在公有云上的集群多考虑第一种模式，在私有云环境中由于维护额外的负载均衡器也是一项负担，建议考虑第二种或是第三种方案。
kube-controller-manager与kube-scheduler高可用
这两项服务是Master节点的一部分，他们的高可用相对容易，仅需要运行多份实例即可。这些实例会通过向apiserver中的Endpoint加锁的方式来进行leader election， 当目前拿到leader的实例无法正常工作时，别的实例会拿到锁，变为新的leader。
目前在多个Master节点上采用static pod模式部署这两项服务的方案比较常见，激进一点也可以采用self-hosted的模式，在Kubernetes之上用DaemonSet或者Deployment来部署。
Kube-dns高可用
严格来说kube-dns并不算是Master组件的一部分，因为它是可以跑在Node节点上，并用Service向集群内部提供服务的。但在实际环境中， 由于默认配置只运行了一份kube-dns实例，在其升级或是所在节点当机时，会出现集群内部dns服务不可用的情况，严重时会影响到线上服务的正常运行。
为了避免故障，请将kube-dns的replicas值设为2或者更多，并用anti-affinity将他们部署在不同的Node节点上。这项操作比较容易被疏忽，直到出现故障时才发现原来是kube-dns只运行了一份实例导致的故障。
- 5自动化部署（单节点伪分布式集群）
环境信息
操作系统：CentOS 7(最小化)、内存2G/硬盘30G以上
配置： 基础网络、更新源、SSH登录等
注意: 确保在干净的系统上开始安装，不能使用曾经装过kubeadm或其他k8s发行版的环境
下载文件
开源代码下载链接：https://codeload.github.com/easzlab/kubeasz/zip/refs/heads/master
代码文件整体结构如下：
将两个脚本拷贝到环境上
ezctl:自动化控制shell脚本，负责自动安装k8s
ezdown:自动下载依赖脚本
使用ezdown下载依赖
默认下载最新推荐k8s/docker等版本（更多关于ezdown的参数，运行./ezdown 查看）
./ezdown -D
可选下载离线系统包 (适用于无法使用yum/apt仓库情形)
./ezdown -P（内网待验证）
上述脚本运行成功后，所有文件（kubeasz代码、二进制、离线镜像）均已整理好放入目录/etc/kubeasz
/etc/kubeasz 包含 kubeasz 版本为 ${release} 的发布代码
/etc/kubeasz/bin 包含 k8s/etcd/docker/cni 等二进制文件
/etc/kubeasz/down 包含集群安装时需要的离线容器镜像
/etc/kubeasz/down/packages 包含集群安装时需要的系统基础软件
安装集群
容器化运行 kubeasz，详见ezdown 脚本中的 start_kubeasz_docker 函数
./ezdown -S
使用默认配置安装 aio 集群
docker exec -it kubeasz ezctl start-aio
然后等待各种自动化配置结束
验证安装k8s
kubectl version
# 验证集群版本
kubectl get node
# 验证节点就绪 (Ready) 状态
kubectl get pod -A
# 验证集群pod状态，默认已安装网络插件、coredns、metrics-server等
kubectl get svc -A
# 验证集群服务状态
集群搭建成功！
helm3安装：
wget https://get.helm.sh/helm-v3.2.4-linux-amd64.tar.gz
tar -zxvf helm-v3.2.4-linux-amd64.tar.gz
mv ./linux-amd64/helm /usr/bin
helm version
启用阿里云 charts 仓库
helm repo add apphub https://apphub.aliyuncs.com/
helm安装成功！
- 6自动化部署（三节点高可用集群）
三Node节点k8s部署
节点是poxos算法的实现需要奇数个节点，最小为三个节点。
三个节点的环境准备(e.g 192.168.137.11/12/13）:
操作系统：CentOS 7(最小化)、内存2G/硬盘30G以上
配置： 基础网络、更新源、SSH登录等
注意: 确保在干净的系统上开始安装，不能使用曾经装过kubeadm或其他k8s发行版的环境
使用python2.7安装ansible
yum update
# 安装python
yum install python -y
# 注意pip 21.0以后不再支持python2和python3.5，需要如下安装
# To install pip for Python 2.7 install it from https://bootstrap.pypa.io/2.7/ :
curl -O https://bootstrap.pypa.io/pip/2.7/get-pip.py
python get-pip.py
python -m pip install --upgrade "pip < 21.0"
(网速慢下来不下来用下面这种)
python get-pip.py -i http://pypi.douban.com/simple/ --trusted-host pypi.douban.com
# pip安装ansible(国内如果安装太慢可以直接用pip阿里云加速)
pip install ansible -i Simple Index
# 更安全 Ed25519 算法
ssh-keygen -t ed25519 -N '' -f ~/.ssh/id_ed25519
# 或者传统 RSA 算法
ssh-keygen -t rsa -b 2048 -N '' -f ~/.ssh/id_rsa
ssh-copy-id $IPs #$IPs为所有节点地址包括自身，按照提示输入yes 和root密码
下载所需要的依赖
chmod +x ./ezdown
./ezdown -D
上述脚本运行成功
后，所有文件（kubeasz代码、二进制、离线镜像）均已整理好放入目录/etc/kubeasz
创建集群配置实例
./ezctl new k8s-01
vi /etc/kubeasz/clusters/k8s-01/hosts
将所有的ip改成自己的集群的ip
/etc/kubeasz/clusters/k8s-01/config.yml
可以使用默认配置不对其进行修改
根据配置进行安装（自动化）
ezctl setup k8s-01 all
自动部署成功！
各节点验证安装：
kubectl version
# 验证集群版本
kubectl get node
# 验证节点就绪 (Ready) 状态
kubectl get pod -A
# 验证集群pod状态，默认已安装网络插件、coredns、metrics-server等
kubectl get svc -A
# 验证集群服务状态
快速命令
kubectl version
kubectl get node
kubectl get pod -A
kubectl get svc -A
Kubectl找不到，先将二进制文件复制到/usr/bin下面
三节点直接搭建成功！
常见问题解决：
Ip配错了 /etc/kubeasz/clusters/k8s-01/hosts 进行修改
无权进行ssh登录，再次使用copy-ssh-ip命令
如果出现6443端口访问不了的问题，大概率是环境被污染了，重装系统之后，以纯净系统安装K8s!
【本文正在参与炫"库"行动-人大金仓有奖征文】
活动链接：CSDN
