K8S前世今生(1)

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，除此以外，管理员可以可以创建新的名字空间满足需要。

负载均衡（LB）在微服务架构演进中具有非常重要的意义，可以说的内容有很多， 这里仅仅讨论四层和七层负载均衡的一些要点和区别 ，以便于对 ingress 的理解。所谓四层和七层负载均衡是按照网络层次OSI来划分的负载均衡类型（也可以按照其他的规则来分类，比如：应用的地理结构），简单来说： 四层负载均衡 表示负载均衡器用ip+port接收请求，再直接转发到后端对应的服务上，工作在传输层( transport layer )； 七层负载均衡 表示负载均衡器根据虚拟的url或主机名来接收请求，经过处理后再转向相应的后端服务上，工作在应用层( application layer )。

下图表示了4层和7层负载均衡在建立TCP连接上的区别，从图中可以看出，四层负载均衡需要建立的TCP连接其实之有一个，它只做一次转发，client直接和server连接；而7层负载均衡则需要建立两次TCP连接，client到LB，LB根据消息中的内容( 比如URL或者cookie中的信息 )来做出负载均衡的决定，接着建立LB到server的连接。

7层负载均衡有什么好处呢？

举个例子：
正向代理 ：在使用VPS访问 的时候，通常会使用一个本地的代理服务器，浏览器的网络包会先经过本地的代理服务器，代理服务器会通过远在异国它乡的电脑来访问 并返回消息；这就好比去附近的咖啡店要先问一下手机咖啡店在哪里一样，手机就是一个正向代理服务器。
反向代理 ：当访问的请求到达 时， 那边也设置了一个代理服务器，它通过查看请求的URL，发现是想查找视频内容，于时把消息转给了视频搜索服务器（过程是我乱说的），这就好比你去朋友家做客，开门的却是个管家，问你找谁？这时候管家就是一个反向代理了。
关于反向代理的好处这里就不多介绍，感兴趣可以看 这里

k8s 对外 暴露服务（service）主要有两种方式： NotePort , LoadBalance ， 此外 externalIPs 也可以使各类service对外提供服务，但是当集群服务很多的时候，NodePort方式最大的缺点是会占用很多集群机器的端口；LB方式最大的缺点则是每个service一个LB又有点浪费和麻烦，并且需要k8s之外的支持； 而ingress则只需要一个NodePort或者一个LB就可以满足所有 service 对外服务的需求。工作机制大致可以用下图表示：

实际上， ingress 相当于一个7层的负载均衡器，是k8s对反向代理的一个抽象。大概的工作原理也确实类似于Nginx，可以理解成在 Ingress 里建立一个个映射规则 , ingress Controller 通过监听 Ingress 这个api对象里的配置规则并转化成 Nginx 的配置（kubernetes声明式API和控制循环） , 然后对外部提供服务。ingress包括： ingress controller 和 ingress resources

ingress controller ：核心是一个deployment，实现方式有很多，比如nginx, Contour, Haproxy, trafik, Istio，需要编写的yaml有：Deployment, Service, ConfigMap, ServiceAccount（Auth），其中service的类型可以是NodePort或者LoadBalancer。

ingress resources ：这个就是一个类型为 Ingress 的k8s api对象了，这部分则是面向开发人员。

假设已经有两个服务部署在了k8s集群内部：

配置 Ingress resources，即可实现多个service对外暴露服务:
方式一：

接着在hosts文件中添加一条解析规则： ${ingress_IP} foobarcom ，这时通过 在浏览器 中访问： foobarcom/coffee 或者 foobarcom/tea 即可访问对应的后端service了。

方式二：

这时在hosts文件添加两条解析规则就可以在浏览器中访问了。此外，还可以配置TLS证书实现>

可以通过--kubeconfig 命令行参数来选择 *** 作不同集群

使用默认的 kubeconfig 文件， 需要将多个 kubeconfig 合并，保存在kubeconfig 的默认位置 $HOME/kube/config , 合并后的参考格式如下：

kubeconfig 中定义了 (clusters)集群、(users)用户和 以及相关联的(contexts)上下文，如果使用Uk8s 可以在控制台: 概览-> 内网凭证/外网凭证 查看需要的凭证，然后按照上述格式补全即可

方式三：使用ansible Playbook 来管理集群内的容器应用

场景描述: 目前我们需要使用helm安装一个external-dns 用来将 ingess对接的域名解析规则，自动同步到DNS服务器，使用shell命令 *** 作参考如下：

将以上 *** 作转化为 ansible-playbook 的tasks 可以拆分为四个 tasks ，

将上诉文件保存为 deploy_external_dnsyaml, 执行命令 ansible-playbook deploy_external_dnsyaml 命令执行成功回看到返回如下类似结果：

方式四：使用ansible-playbook roles来组织管理集群变更tasks

在方式三中，如果是管理一个集群，编写一个deploy_external_dnsyaml就能完成工作，如果管理多个集群，就要编写多个yaml文件，并且重复编写很多差异不多的tasks 实际 *** 作可能类似这个样子：

经过对比分析，这些tasks 主要差异变量：

只要将以上两个变量参考可配置化，最原始的四个 tasks就可以复用，然后使用 Ansible role 重新组织tasks 文件，拆分为两个role：

其中 external_dns 依赖 helm-repository 然后目录结构如下

roles/helm-repository/mainyml

roles/external-dns/tasks/mainyml

roles/external-dns/meta/mainyml

新建一个文件 deploy-chart-external-dns 来引用 role：helm-repository

最后，仅仅需要维护一个可复用的 role：helm-repository ，以及在deploy-chart-external-dns 定义要集群属性等变量，就可以轻松的维护多集群内的各类容器应用了

执行命令：ansible-playbook deploy-chart-external-dns 返回结果如下：

grep -E '(vmx|svm)' /proc/cpuinfo

yum install qemu virt kvm -y

Question：

Solution：已安装的跳过

yum install qemu virt kvm -y --skip-broken

systemctl start libvirtd

systemctl enable libvirtd

virsh list

yum install -y bridge-utils

#配置桥接模式

cd /etc/sysconfig/network-scripts

cp ifcfg-em2 ifcfg-br0

[root@localhost network-scripts]# vim ifcfg-em2

TYPE=Ethernet

BRIDGE=br0

NAME=em2

UUID=74c8085f-4c0d-4743-b0a0-70e51e3eb877

DEVICE=em2

ONBOOT=yes

#注意IPADDR 要改为自己的

[root@localhost network-scripts]# vim ifcfg-br0

TYPE=Bridge

PROXY_METHOD=none

BROWSER_ONLY=no

BOOTPROTO=none

DEFROUTE=yes

IPV4_FAILURE_FATAL=no

IPV6INIT=yes

IPV6_AUTOCONF=yes

IPV6_DEFROUTE=yes

IPV6_FAILURE_FATAL=no

IPV6_ADDR_GEN_MODE=stable-privacy

NAME=br0

DEVICE=br0

ONBOOT=yes

IPADDR=17216103

PREFIX=24

GATEWAY=1721610254

DNS1=114114114114

systemctl restart network

#验证

brctl show

cd /home/kvm

#创建master虚拟机的存储盘 104

qemu-img create -f qcow2 -o cluster_size=2M k8s-master01qcow2 200G

virt-install --virt-type kvm --os-type=linux --os-variant rhel7 --name k8s-master01qcow2 --memory 8192 --vcpus 4 --disk /home/kvm/k8s-master01qcow2,format=qcow2 --cdrom /home/kvm/CentOS-7-x86_64-DVD-2009iso --network bridge=br0 --graphics vnc,listen=0000 --noautoconsole

#创建worker虚拟机的存储盘 105

qemu-img create -f qcow2 -o cluster_size=2M k8s-worker01qcow2 200G

virt-install --virt-type kvm --os-type=linux --os-variant rhel7 --name k8s-worker01qcow2 --memory 8192 --vcpus 4 --disk /home/kvm/k8s-worker01qcow2,format=qcow2 --cdrom /home/kvm/CentOS-7-x86_64-DVD-2009iso --network bridge=br0 --graphics vnc,listen=0000 --noautoconsole

#创建worker虚拟机的存储盘 103

qemu-img create -f qcow2 -o cluster_size=2M k8s-worker02qcow2 200G

virt-install --virt-type kvm --os-type=linux --os-variant rhel7 --name k8s-worker02qcow2 --memory 32768 --vcpus 32 --disk /home/kvm/k8s-worker02qcow2,format=qcow2 --cdrom /home/kvm/CentOS-7-x86_64-DVD-2009iso --network bridge=br0 --graphics vnc,listen=0000 --noautoconsole

netstat -ntlp | grep 5900

virsh list --all

virsh shutdown k8s-master01qcow2

virsh start k8s-master01qcow2

ssh 172161050 root@starQuest2022

Question：系统启动卡住

Solution：

virsh destroy k8s-master01qcow2

virsh undefine k8s-master01qcow2

Question：更改桥接模式失败引发的问题

Solution：

vi /etc/sysconfig/network-scripts/ifcfg-eth0

TYPE=Ethernet

PROXY_METHOD=none

BROWSER_ONLY=no

BOOTPROTO=static

DEFROUTE=yes

IPV4_FAILURE_FATAL=no

IPV6INIT=yes

IPV6_AUTOCONF=yes

IPV6_DEFROUTE=yes

IPV6_FAILURE_FATAL=no

IPV6_ADDR_GEN_MODE=stable-privacy

NAME=eth0

UUID=c510f2f9-9820-45e8-9c70-65674bd35258

DEVICE=eth0

ONBOOT=yes

IPADDR=172161050

PREFIX=24

GATEWAY=1721610254

DNS1=114114114114

systemctl restart network

Question：

Solution：

vi /root/ssh/known_hosts 删除有问题IP对应行

#设置hostname

hostnamectl set-hostname k8s-master01

hostnamectl set-hostname k8s-worker01

hostnamectl set-hostname k8s-worker02

yum update

yum install wget

yum install vim

rpm --import >