如果在本地搭建，我们可以使用haproxy+keepalived方式轻松实现k8s中的负载均衡，但是阿里的ecs不能使用keepalived,所以我们被迫只能使用阿里的 slb了。
既然keepalived的方式不能使用，那我们就使用阿里的slb进行负载均衡呗，由于该负载均衡不需要被外部访问，只提供对k8s集群节点之间的访问,所以我们就使用私网的slb。
[上传失败(image-b02d7-1604545387128)]
我们保证该slb和k8s集群节点的node属于同一个局域网内，具体配置如下
第一步就是监听该slb的6443端口，该端口后端的服务器组分别是3台ecs的6443端口(apiserver服务)。接着我们可以 在master1节点 上执行如下命令
由于后端服务器组的 apiserver 都尚未运行，预期会出现一个连接拒绝错误。然而超时意味着负载均衡器不能和控制平面节点通信。 如果发生超时，请重新配置负载均衡器与控制平面节点进行通信。
我们在master1节点上创建kubeadm-configyaml文件，用于初始化控制平面节点，如下。
接着我们在master1节点上执行如下命令初始化
最后结果如下
看上面的日志好像是kubelet的问题。我们先确认kubelet是否运行,发现处于running状态。
接着查看kubelet的日志
发现一个奇怪的问题，>本文主要在centos7系统上基于 docker 和 flannel 组件部署 v1236 版本的k8s原生集群，由于集群主要用于自己平时学习和测试使用，加上资源有限，暂不涉及高可用部署。
此前写的一些关于k8s基础知识和集群搭建的一些 方案 ，有需要的同学可以看一下。
机器均为8C8G的虚拟机，硬盘为100G。
同一个k8s集群内的所有节点需要确保 mac 地址和 product_uuid 均唯一，开始集群初始化之前需要检查相关信息
如果k8s集群的节点有多个网卡，确保每个节点能通过正确的网卡互联访问
这里可以根据自己的习惯选择ntp或者是chrony同步均可，同步的时间源服务器可以选择阿里云的 ntp1aliyuncom 或者是国家时间中心的 ntpntscaccn 。
k8s集群之间通信和服务暴露需要使用较多端口，为了方便，直接禁用防火墙
这里主要是需要配置内核加载 br_netfilter 和 iptables 放行 ipv6 和 ipv4 的流量，确保集群内的容器能够正常通信。
虽然新版本的k8s已经支持双栈网络，但是本次的集群部署过程并不涉及IPv6网络的通信，因此关闭IPv6网络支持
IPVS是专门设计用来应对负载均衡场景的组件， kube-proxy 中的 IPVS 实现 通过减少对 iptables 的使用来增加可扩展性。在 iptables 输入链中不使用 PREROUTING，而是创建一个假的接口，叫做 kube-ipvs0，当k8s集群中的负载均衡配置变多的时候，IPVS能实现比iptables更高效的转发性能。
详细的官方文档可以参考 这里 ，由于在刚发布的124版本中移除了 docker-shim ，因此安装的 版本≥124 的时候需要注意 容器运行时 的选择。这里我们安装的版本低于124，因此我们继续使用docker。
docker的具体安装可以参考我之前写的 这篇文章 ，这里不做赘述。
CentOS7使用的是 systemd 来初始化系统并管理进程，初始化进程会生成并使用一个 root 控制组 ( cgroup ), 并充当 cgroup 管理器。 Systemd 与 cgroup 集成紧密，并将为每个 systemd 单元分配一个 cgroup 。 我们也可以配置 容器运行时 和 kubelet 使用 cgroupfs 。 连同 systemd 一起使用 cgroupfs 意味着将有两个不同的 cgroup 管理器 。而当一个系统中同时存在cgroupfs和systemd两者时，容易变得不稳定，因此最好更改设置，令容器运行时和 kubelet 使用 systemd 作为 cgroup 驱动，以此使系统更为稳定。 对于 Docker, 需要设置 nativecgroupdriver=systemd 参数。
k8s官方有 详细的文档 介绍了如何设置kubelet的 cgroup driver ，需要特别注意的是，在122版本开始，如果没有手动设置kubelet的cgroup driver，那么默认会设置为systemd
一个比较简单的指定kubelet的 cgroup driver 的方法就是在 kubeadm-configyaml 加入 cgroupDriver 字段
我们可以直接查看configmaps来查看初始化之后集群的kubeadm-config配置。
当然因为我们需要安装的版本高于1220并且使用的就是systemd，因此可以不用再重复配置。
kube三件套就是 kubeadm 、 kubelet 和 kubectl ，三者的具体功能和作用如下：
需要注意的是：
CentOS7的安装比较简单，我们直接使用官方提供的 yum 源即可。需要注意的是这里需要设置 selinux 的状态，但是前面我们已经关闭了selinux，因此这里略过这步。
在集群中所有节点都执行完上面的三点 *** 作之后，我们就可以开始创建k8s集群了。因为我们这次不涉及高可用部署，因此初始化的时候直接在我们的目标master节点上面 *** 作即可。
此时我们再查看对应的配置文件中的镜像版本，就会发现已经变成了对应阿里云镜像源的版本
当我们看到下面这个输出结果的时候，我们的集群就算是初始化成功了。
刚初始化成功之后，我们还没办法马上查看k8s集群信息，需要配置kubeconfig相关参数才能正常使用kubectl连接apiserver读取集群信息。
配置完成后，我们再执行相关命令就可以查看集群的信息了。
这时候我们还需要继续添加剩下的两个节点作为worker节点运行负载，直接在剩下的节点上面运行集群初始化成功时输出的命令就可以成功加入集群：
如果不小心没保存初始化成功的输出信息也没有关系，我们可以使用kubectl工具查看或者生成token
添加完成之后我们再查看集群的节点可以发现这时候已经多了两个node，但是此时节点的状态还是 NotReady ，接下来就需要部署CNI了。
flannel 应该是众多开源的CNI插件中入门门槛最低的CNI之一了，部署简单，原理易懂，且相关的文档在网络上也非常丰富。
针对 kube-flannelyml 文件，我们需要修改一些 参数 以适配我们的集群：
修改完成之后我们直接部署即可
集群部署完成之后我们在k8s集群中部署一个nginx测试一下是否能够正常工作。首先我们创建一个名为 nginx-quic 的命名空间（ namespace ），然后在这个命名空间内创建一个名为 nginx-quic-deployment 的 deployment 用来部署pod，最后再创建一个 service 用来暴露服务，这里我们先使用 nodeport 的方式暴露端口方便测试。
部署完成后我们直接查看状态
最后我们进行测试，这个nginx-quic的镜像默认情况下会返回在nginx容器中获得的用户请求的IP和端口
# kubeadm init \
--apiserver-advertise-address=10170208111 \
--image-repository registryaliyuncscom/google_containers \
--kubernetes-version=v1194 \
--service-cidr=109600/12 \
--pod-network-cidr=1024400/16 \
--token-ttl=0
安装方式建议实用kubeadm安装方式
kubectl taint nodes --all node-rolekubernetesio/master-
wget >Kubernetes 10版本发布已经过去了4年，繁荣的社区和广泛用户群体使得Kubernetes的成熟度超出了预期，大部分用户常用的功能性需求都得到了满足。但是，根据CNCF的调查，很多非功能性的需求尚待完善，比如，用户所面临的最困难的挑战之一仍然是管理多个Kubernetes集群的生命周期，包括集群部署、升级和变更等。Kubernetes社区未来的一个阶段的重点就是帮助用户更好的部署和维护Kubernetes，使其无缝的融入和对接现有的企业环境。
Kubernetes现在已经可以支持超大规模的集群，单集群可以支撑5000个节点，15万个POD。但是由于大规模集群的维护和调度过于复杂，比如，有些企业应用需要分级，不同级别的应用需要使用不同的资源池，有些业务应用需要带有GPU支持的集群，有些应用需要Windows container的支持，甚至不同应用依赖不同版本的Kubernetes，所以在企业环境中通过多集群的方式实现多租户和资源调度已经成为了最佳实践。
当你需要管理多个集群，每个集群都有不同的规模、版本、升级计划、硬件资源池，自动化的管理工具和理念就必不可少了。
我们知道，Kubernetes的很多原则和理念改变了传统资源管理和交付的模式，其中声明式API和自愈机制的引入提升了用户部署和管理应用的效率。它允许用户通过yaml文件描述对象部署的期望状态（比如部署3个POD实例），并持续观测当前状态，如果和预期不一致（只剩2个POD实例），就通过控制器使其达到期望状态（添加1个POD实例，使总数为预期的3个）。
既然这种模式如此的成功，能不能把它适用到更多的场景中呢？比如，能不能用Kubernetes的思想来管理Kubernetes的集群呢？
实际上社区中已经有人这么做了，Cluster API 就是在这个背景下，由google，vmware等公司共同发起的项目。 >
4C4G机器设置为k8smaster节点，另外一台机器设置为k8snode节点
分别进入两台的 /ect/hosts 目录，设置r如下host
由于k8s内部节点之间的通讯使用的是内网ip，我们需要把内网ip的重定向到公网ip上
由于两台机器是处于公网环境，且k8s节点之间需要通讯，所以需要开放一些端口，端口配置可以直接进到腾讯云控制台进行配置
以下是官网要求的master节点的端口配置
可以进入腾讯云服务器的防火墙配置开放相应端口，端口可以限定来源，只允许node节点(19216822)访问
以下是官网要求的node节点的端口配置
同理，也设置node节点的端口
master节点需要安装
node节点需要安装
添加安装源(所有节点)
安装命令
设置开机启动
修改docker配置（所有节点）
组件安装完成后就可以启动了，首先启动master节点，然后让node节点加入master几点即可。
在master节点使用kubeadm初始化集群
这里需要保存token，token是用于node节点加入maste节点的凭证
node节点加入master节点
安装网络插件，否则node是NotReady状态（主节点跑）
kubectl get nodes
Kubernetes是如今IT领域最火热的关键字，本文回顾Kubernetes的历史，介绍Kubernetes的基础概念，并和大家更为熟悉的虚拟化技术作类比加深对Kubernetes的理解，同时分析Kubernetes的优势劣势，最后展望未来。
有人认为自动化，云计算和人工智能是第四次工业革命。如果你开始感受到IT领域自动化率的飙升，特别是在应用程序部署和管理领域（我觉得还不是无缝的自插拔式），那么不用太过惊讶。几年前，Google就正式启动了名为Kubernetes的项目，也就是现在广为人知的k8s。Kubernetes是开源的容器集群管理器，意图成为能够在容器领域自治化部署以及扩展应用程序的平台。
Kubernetes是一个可移植的，可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。Kubernetes的服务，支持和工具广泛可用。
Kubernetes这个名字起源于希腊语，意思是舵手或飞行员。Google在2014年开源了Kubernetes项目。Kubernetes将 超过15年的Google 在大规模生产工作负载方面 的经验 与社区中最好的想法和实践相结合。
让我们回顾一下为什么Kubernetes如此有用。
传统部署时代： 早期，组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况，结果，其他应用程序的性能将下降。解决方案是在不同的物理服务器上运行每个应用程序。但这并没有随着资源利用不足而扩展，并且组织维护许多物理服务器的成本很高。
虚拟化部署时代： 作为解决方案，引入了虚拟化。它允许您在单个物理服务器的CPU上运行多个虚拟机（VM）。虚拟化允许在VM之间隔离应用程序，并提供安全级别，因为一个应用程序的信息不能被另一应用程序自由访问。
虚拟化可以更好地利用物理服务器中的资源，并可以实现更好的可伸缩性，因为可以轻松地添加或更新应用程序，降低硬件成本等等。借助虚拟化，您可以将一组物理资源呈现为一组一次性虚拟机。
每个VM都是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的 *** 作系统。
容器部署时代： 容器类似于VM，但是它们具有轻松的隔离属性，可以在应用程序之间共享 *** 作系统（OS）。因此，容器被认为是轻质的。与VM相似，容器具有自己的文件系统，CPU，内存，进程空间等。由于它们与基础架构分离，因此可以跨云和OS分发进行移植。
容器之所以受欢迎，是因为它们提供了额外的好处，例如：
容器是捆绑和运行应用程序的好方法。在生产环境中，您需要管理运行应用程序的容器，并确保没有停机时间。例如，如果一个容器发生故障，则需要启动另一个容器。如果此行为由系统处理，会不会更容易？
这就是Kubernetes的救援方法！Kubernetes为您提供了一个可d性运行分布式系统的框架。它负责应用程序的扩展和故障转移，提供部署模式等。例如，Kubernetes可以轻松管理系统的Canary部署。
Kubernetes为您提供：
Kubernetes不是一个传统的，包罗万象的PaaS（平台即服务）系统。由于Kubernetes在容器级别而非硬件级别运行，因此它提供了PaaS产品共有的一些普遍适用的功能，例如部署，扩展，负载平衡，并允许用户集成其日志记录，监视和警报解决方案。但是，Kubernetes并不是单片的，这些默认解决方案是可选的和可插入的。Kubernetes提供了构建开发人员平台的基础，但是在重要的地方保留了用户的选择和灵活性。
Kubernetes：
在深入研究Kubernetes之前，要认识到如果没有容器的出现，Kubernetes也不会存在。从高层看，容器看上去像虚拟机，但是最大的区别是容器和其他容器共享主机系统的内核。这是最主要的差异要素，因为容器共享物理主机的OS，所以它们很容易移动。用户也可以在同一台主机上启动比VM数量多得多的容器，因为它们共享内核，库和二进制文件。比如，一个VM的大小大概是20GB，而运行着相同应用程序的容器大概只有200MB。
容器（无论是Docker还是CoreOS的rkt）允许开发人员无缝地关注于应用程序的运行时。基础架构的问题会影响到脆弱的应用程序开发的日子一去不复返了。使用容器，开发人员仅仅需要考虑如何恰当地扩展，部署以及管理他们新开发的应用程序，但是现有的容器方案并不能在跨多节点的环境里自己管理，调度以及部署容器。
在容器化的世界里，Kubernetes是环境的管理和部署引擎。使用Kubernetes的最基本功能，用户就可以轻松地在物理硬件或者虚拟机上调度并且运行应用程序。Kubernetes的更多高级用法让开发人员可以彻底摆脱主机为中心的世界，而进入容器为中心的环境里。
使用Kubernetes很容易。可以使用REST API来 *** 作Kubernetes所包含的主要组件 。Kubernetes的定位是平台，但是它包含多个组件，每个都有各自的角色。Master是Kubernetes集群里的控制服务（也称为control plane），Master很重要，因为它会API调用和其交互的其他组件。集群单元管理发生在Master里，调度服务也在这里。
Kubernetes架构介绍，Imesh Gunaratne 。
Master之下就是Kubernetes工作单元，这里定义特定工作的实体。既然最终目标是要交付一个应用程序，那么这些单元还有更多其他的特定功能。
Pod ：最基础的单元是Pod，当指派容器时，容器实际上并不会指派到物理硬件上，相反，容器会被分配到一个Pod里。Pod通常负责托管服务于单个应用程序的容器。这意味着Pod内的所有容器都能够共享卷和IP空间，允许它们扩展为单个应用程序。
Service（服务） ：如果想要构建更为稳健的容器化策略，那么“服务”的概念就更加重要。服务的功能是资源均衡器，将工作负载在容器间导流。这使得后台容器可以通过单一稳定的接入点和前端应用程序通信。这个特性让使用者更易于使用并且可扩展。
Replication Controller（副本控制器） ：这些单元的目的是确保在某个时间点，有所需数量的特定容器在运行。比如说突然某个内核出错了，导致某个容器（多个容器组内的）崩溃了，那么RC的责任是新启动一个副本Pod，直至之前的Pod在重启后恢复为止。一旦之前的Pod启动并且再次运行了，RC就会杀死副本Pod。
Label（标签） ：虽然标签并不是一种工作单元，但是它起着至关重要的组织作用。标签的功能是组命名，这样用户可以针对一组单元做 *** 作。这是用户组织容器环境的方式。
在最基础的级别上，这些是组成Kubernetes平台的实体。
想一想我们现在都很熟悉的技术，通过虚拟化类比一下Kubernetes。
Kubernetes的Master和VMware的vCenter类似。Master知道集群里的所有节点，以及所有节点的容量。而且，Master对Pod的调度及放置，类似于vCenter如何在vSphere的主机上部署VM。Pod的功能和vApp很类似，因为它们都在一个网络里托管多个容器。容器类似VM，因为它们之前都是互相隔离的，除非它们被指定特定的网络路径。最后，Replication Controller类似于HA，因为RC持续监控环境，确保正确数量的Pod在运行，如果数量少于预期，就会调度一个新的实例。
虽然Kubernetes并不是市场里唯一的容器管理平台（还有Docker Swarm和Mesos），但是它更受欢迎。为什么呢？从高层看，Kubernetes正获得关注，因为它提供了这样一个平台，容器化的应用程序可以只编写一次，就能够在所有类型的云供应商以及私有云上运行，无论底层使用的是哪种基础架构。而且，Kubernetes还在发展，让开发人员能够在Kubernetes上运行任意适合的应用程序。Sam Ghods，Box的联合创始人认为只要是能运行的二进制文件，就可以运行在Kubernetes上。
使用Kubernetes，开发人员可以快速部署应用程序，而无需担心传统平台上的诸多风险（想想跨多OS环境的垂直扩展），可以随时扩展应用程序，并且更好地分配资源。
硬件使用量的下降是使用Kubernetes带来的另一个好处。一些公司报告由于容器的轻量天性，以及能够快速杀死不需要的实体（和传统架构相比），硬件使用量减少了40-50%。eBay是Kubernetes的支持者和用户，声称自从他们切换了平台之后，看到了服务器上[overhead的急剧降低]
最后，Kubernetes最大的不同之处并非和技术相关，而是促成各种方案的社区。Google将其发布为开源项目，吸引了1000+的社区贡献者，34000次commit。它的社区比Mesos的社区（次大的竞争者社区）大5倍，比所有竞争者的社区加起来都要大。
Kubernetes受到了广泛的称赞，但是它也有一些缺点。当第一次使用它做部署（大规模）时，它很复杂，并且很难搭建。它要求具有特定技能的工程师，在现在的行业里可能很难找到。
第二，Kubernetes作为容器的第三方管理系统。容器技术本身的缺陷和成长之痛会影响到Kubernetes所能够提供的服务。
Kubernetes欠缺的领域是调度器。默认的Kubernetes调度器依赖于应用程序所有者提供的分配资源的需求，而不管实时使用量。这个方案会加重每个节点上的资源分片情况。
最后，能够在容器里运行的工作负载范围将影响Kubernetes的广泛使用，但是这并非Kubernetes可以直接解决的问题。比如，很多工程师还不想把“核心”工作负载放到容器里，因为它可能会崩溃，而容器从设计上就不是为了存储数据的。常见的实践是只在容器里运行那些崩溃后也不会导致下线时间的应用程序。
即使有这些不足，也并没有阻止Goldman Sachs，Box，SAP以及The New York Times这样的公司引入Kubernetes平台作为其下一代数据中心计划的一部分。
应用程序是如今大多数业务的生命线。公司需要快速的部署和高质量的应用程序。这些需求正是开发人员转向容器的原因。随着容器的发展，如果还认为Kubernetes的定位有问题那就难免有些愚蠢了。Kubernetes平台有很多的可能性，但是规模大了的话它也很难管理。最初的搭建和在生产环境上大规模运行Kubernetes之间的空白是很大的。近几年里，可能会有来自于第三方的强劲挑战，来管理这些部署和工作负载。对于Kubernetes来说，不囿于已经取得的成就至关重要。如果社区能够恰当地扩展平台，那么Kubernetes的前途甚为光明。
Kubernetes借鉴了Borg的设计理念，比如Pod、Service、Labels和单Pod单IP等。Kubernetes的整体架构跟Borg非常像，如下图所示：
Kubernetes主要由以下几个核心组件组成：
除了核心组件，还有一些推荐的Add-ons：
Kubernetes Architecture
Kubernetes Master
Kubernetes Node
API对象是K8s集群中的管理 *** 作单元。K8s集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的API对象，支持对该功能的管理 *** 作。例如副本集Replica Set对应的API对象是RS。
每个API对象都有3大类属性：元数据metadata、规范spec和状态status。元数据是用来标识API对象的，每个对象都至少有3个元数据：namespace，name和uid；除此以外还有各种各样的标签labels用来标识和匹配不同的对象，例如用户可以用标签env来标识区分不同的服务部署环境，分别用env=dev、env=testing、env=production来标识开发、测试、生产的不同服务。规范描述了用户期望K8s集群中的分布式系统达到的理想状态（Desired State），例如用户可以通过复制控制器Replication Controller设置期望的Pod副本数为3；status描述了系统实际当前达到的状态（Status），例如系统当前实际的Pod副本数为2；那么复制控制器当前的程序逻辑就是自动启动新的Pod，争取达到副本数为3。
K8s中所有的配置都是通过API对象的spec去设置的，也就是用户通过配置系统的理想状态来改变系统，这是k8s重要设计理念之一，即所有的 *** 作都是声明式（Declarative）的而不是命令式（Imperative）的。声明式 *** 作在分布式系统中的好处是稳定，不怕丢 *** 作或运行多次，例如设置副本数为3的 *** 作运行多次也还是一个结果，而给副本数加1的 *** 作就不是声明式的，运行多次结果就错了。
Cluster 是计算、存储和网络资源的集合，Kubernetes 利用这些资源运行各种基于容器的应用。
Master 是 Cluster 的大脑，它的主要职责是调度，即决定将应用放在哪里运行。Master 运行 Linux *** 作系统，可以是物理机或者虚拟机。为了实现高可用，可以运行多个 Master。
Node 的职责是运行容器应用。Node 由 Master 管理，Node 负责监控并汇报容器的状态，并根据 Master 的要求管理容器的生命周期。Node 运行在 Linux *** 作系统，可以是物理机或者是虚拟机。
Pod 是 Kubernetes 的最小工作单元。每个 Pod 包含一个或多个容器。Pod 中的容器会作为一个整体被 Master 调度到一个 Node 上运行。
Kubernetes 引入 Pod 主要基于下面两个目的：
Kubernetes 通常不会直接创建 Pod，而是通过 Controller 来管理 Pod 的。Controller 中定义了 Pod 的部署特性，比如有几个副本，在什么样的 Node 上运行等。为了满足不同的业务场景，Kubernetes 提供了多种 Controller，包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等，我们逐一讨论。
Deployment 是最常用的 Controller，比如前面在线教程中就是通过创建 Deployment 来部署应用的。Deployment 可以管理 Pod 的多个副本，并确保 Pod 按照期望的状态运行。
ReplicaSet 实现了 Pod 的多副本管理。使用 Deployment 时会自动创建 ReplicaSet，也就是说 Deployment 是通过 ReplicaSet 来管理 Pod 的多个副本，我们通常不需要直接使用 ReplicaSet。
DaemonSet 用于每个 Node 最多只运行一个 Pod 副本的场景。正如其名称所揭示的，DaemonSet 通常用于运行 daemon。
StatefuleSet 能够保证 Pod 的每个副本在整个生命周期中名称是不变的。而其他 Controller 不提供这个功能，当某个 Pod 发生故障需要删除并重新启动时，Pod 的名称会发生变化。同时 StatefuleSet 会保证副本按照固定的顺序启动、更新或者删除。
Job 用于运行结束就删除的应用。而其他 Controller 中的 Pod 通常是长期持续运行。
RC、RS和Deployment只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的IP启动一个新的Pod，因此不能以确定的IP和端口号提供服务。要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的的后端服务实例。在K8s集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。在K8s集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是K8s集群内部的负载均衡器。它是一个分布式代理服务器，在K8s的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的Kube-proxy就越多，高可用节点也随之增多。与之相比，我们平时在服务器端做个反向代理做负载均衡，还要进一步解决反向代理的负载均衡和高可用问题。
Kubernetes 运行容器（Pod）与访问容器（Pod）这两项任务分别由 Controller 和 Service 执行。
名字空间为K8s集群提供虚拟的隔离作用，K8s集群初始有两个名字空间，分别是默认名字空间default和系统名字空间kube-system，除此以外，管理员可以可以创建新的名字空间满足需要。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）