搭建k8s集群（平台规划和部署方式介绍）

1、搭建k8s环境平台规划

2、服务器硬件配置要求
测试环境：
master：2核，内存4g，硬盘20g
node：4核，内存8g，硬盘40g

生产环境：
更高要求

3、搭建集群方式

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 >

Kubernetes（简称K8S） 是Google开源的分布式的容器管理平台，方便我们在服务器集群中管理我们容器化应用。

节点 （Master node and Worker node）
节点通常指的就是服务器，在k8s中有两种节点：管理节点（Master Node）和工作节点（Worker Node）
管理节点（Master Node）：负责管理整个k8s集群，一般由3个管理节点组成HA的架构。
工作节点（Worker Node）：主要负责运行容器。

命名空间 (Namespace)
k8s命名空间主要用于隔离集群资源、隔离容器等，为集群提供了一种虚拟隔离的策略；默认存在3个名字空间，分别是默认命名空间 default、系统命名空间 kube-system 和 kube-public。

Object
k8s 对象(Object)是一种持久化存储并且用于表示集群状态的实体。k8s 对象其实就是k8s自己的配置协议，总之我们可以通过定义一个object让k8s根据object定义执行一些部署任务、监控任务等等。

POD
Pod是 Kubernetes 部署应用或服务的最小的基本单位。一个Pod 封装多个应用容器（也可以只有一个容器）、存储资源、一个独立的网络 IP 以及管理控制容器运行方式的策略选项。

副本集 (Replica Set，RS)
是一种控制器，负责监控和维护集群中pod的副本(replicas)数，确保pod的副本数是我们期望的样子。

部署 (Deployment)
表示对k8s集群的一次更新 *** 作，是k8s集群中最常用的Object，主要用于部署应用。支持滚动升级。

服务 (service)
是对应用的抽象，也是k8s中的基本 *** 作单元，一个服务背后由多个pod支持，服务通过负载均衡策略将请求转发到容器中。

Ingress
是一种网关服务，可以将k8s服务通过>

无状态应用 & 有状态应用

无状态应用指的是应用在容器中运行时候不会在容器中持久化存储数据，应用容器可以随意创建、销毁；如果一个应用有多个容器实例，对于无状态应用，请求转发给任何一个容器实例都可以正确运行。例如：web应用

有状态应用指的是应用在容器中运行时候需要稳定的持久化存储、稳定的网络标识、固定的pod启动和停止次序。例如：mysql数据库

k8s是google公司使用go语言开发，借鉴borg系统开发出来的。

k8s集群服务器主要分为两类角色，分别为master和node。

api server： k8s网关，所有指令请求都必须经过apiserver。
scheduler： 调度器 根据调度算法，将请求资源调度到某一个node节点。
controller： 控制器，维护k8s资源对象。
etcd： 分布式存储组件，用于存储资源对象。

docker： 运行容器的基础环境，容器引擎。
kubelet： 每个node节点都存在一份，在node节点上的资源 *** 作指令均由kubelet执行，从etcd扫描相关请求，在节点上执行请求。

kube-proxy： 代理服务，负载均衡
fluentd： 日志收集服务
pod： 是k8s管理的基本单位（最小单元），pod 内部是容器

k8s是用来管理容器的，但是不直接 *** 作容器，最小 *** 作单元为pod
特点：

pod是一个虚拟化的分组（有自己的ip地址、主机名），pod相当于独立主机，可以封装一个或多个容器。通常情况下，一个pod中要么部署一个服务，要么部署多个相关的服务
1、pod底层网络和数据存储：
pod底层网络和存储主要依赖pause容器，该容器作用如下：

2、pod内部容器使用localhost相互访问
3、pod内部容器创建之前必须先创建pause

物理服务器是一种为客户机提供服务的高性能计算机，是构建云计算和数据中心的最核心基础设备，而云服务器和虚拟主机都是基于云计算技术进行研发的。服务器、云服务器和虚拟主机的区别主要表现在以下几个方面：

1、性能方面：服务器的性能好坏影响着后续开发的使用效果，所以服务器必须要有承担服务、保障服务的能力。物理服务器的高性能主要体现在高速度的运算能力、长时间的可靠运行、强大的外部数据吞吐能力等方面，性能方面是最好的。由于云服务器属于公有性质，它的性能瓶颈受到底层服务器的硬件制约。而虚拟主机在使用中一旦数据访问量过大，就会变得卡慢，而且虚拟主机升级也比较麻烦。

2、安全性：传统的物理服务器是独立服务器，只有一个 *** 作系统直接安装在服务器上，专用于单个租户，租户与租户之间是基于物理隔离，安全性最高。云服务器基于云计算的架构，可自主切换故障节点到正常的主机，其稳定性较强，提供多种数据恢复的措施，安全性也是可以的。虚拟主机由于带宽是共享的，虚拟主机使用共享IP的话，安全性就会降低。

3、实惠性：随着云平台的产品的推广逐渐得到大众的认可，云的发展前景越来越好，云服务器的价格也有所降低。这样，用户不仅可以节约自身成本，还能获得高性能、可灵活扩展的计算机资源。与传统物理服务器相比，云服务器更经济实惠。虚拟主机跟相同配置的云服务器相比，会更便宜一些。

4、灵活扩展性：云服务器可支持d性扩展，可根据需求选择云服务器再付费。当服务器性能不能满足企业或用户的业务发展需求时，可以随时进行扩容，升级云服务器的主机CPU、内存、硬盘和带宽等系统配置，能够灵活扩展。而虚拟主机的升级或扩容就相对麻烦，需重新租用新的虚拟主机空间。

5、技能门槛：云服务器通常在控制台中提供先进的管理功能，使云服务器的管理变得更加简单。虚拟主机同样管理相对简单，使用效率更高。物理服务器则需要具备服务器配置知识、细致的规划和管理，以及了解相关所需的资源，需要较为完备的知识储备。

总体来说，云服务器的综合能力是最平均的，随着云计算技术的不断发展，在信息化建设模式上上云是大势所趋。由数通畅联自主研发的UMC云管理平台是云平台开发、部署、管理、运维的统一管理中心，对K8S集群配置、运行状态等进行统一管理，满足云原生四个基本要素：容器化、微服务、DevOPS持续交付、多租户管理。由UMC、容器化的AEAI套件及CI/CD管理机制组合形成了AEAIiPaaS平台。主要通过连接、协同实现业务集成，支撑业务中台，通过连接、共享实现数据集成，成就数据中台。

从 2019 年初开始，就有不少创业公司陆陆续续向我咨询 Kubernetes 等云原生技术。

我总是会问这些创业公司的部署流程是怎样的，因为这能让我大概了解到一个公司的技术复杂度处在哪个阶段。有些公司仅仅使用 scp 部署简单的PHP应用程序，就能让公司走的很远，而有些公司的架构达到极限，不得不使用诸如Redis或者Kafka这样的基础组件作为内部通信，从而将系统拆分为不同的服务。

当他们知道我的履历里有Kubernetes的相关实战经验后，便总会问起它。大多数公司对上手Kubernetes很感兴趣，但同时也对Kubernetes是否适用于特定的用例表示出了担心。我在上一家公司是怎样使用它的？学习它困难吗？开发团队有哪些使用它的经验？

当然，有时候一些关于实施不当的可怕故事会使他们担心迁移到Kubernetes是一个错误。经常听到一些非常合理的怀疑，同时又希望部署更加简单但又犹豫不决已经成为一种常态。

所以这里我直接切入重点。基于我已经在两家非常不同的公司使用了Kubernetes，如果我今天从头开始做一家创业公司，我极有可能从Kubernetes开始。这是我的结论。

简而言之，运用Kubernetes带来的积极因素远远超过了少数不利因素。我认为它值得许多创业公司的投资。并非所有的创业公司，也不一定是你的公司，但是一定有很多这样的公司 。

让我们来看一下几点原因。

Kubernetes最初是由Google开发的开源容器编排系统，后来被贡献给了开源社区，目前有大量新的第三方库和插件（术语叫做operators）。

Kubernetes不是像阿里云或者腾讯云这样的云平台，事实上，你可以在自己的数据中心，硬件上运行和部署Kubernetes，不过我不建议初学者使用。它更像是一种用来描述工作系统的语言。一旦我们对系统进行了足够详细的描述，Kubernetes便可以使用其计算资源（Kubernetes的术语是nodes）来执行系统的容器。

对于初创公司来说，最大的好处就是，这种“描述工作系统”的过程可作为文档和代码的集中位置来定义基础架构 。

我不想撒谎，像AWS或者阿里云的Kubernetes容器服务目前价格偏高，除了最少3到5个实例节点外，还需要一部分管理费。但是请考虑你要花多少钱才能让工程师手动启动节点。这些纯粹的基础架构变更所浪费的时间仅仅是在开发产品上花费的时间。如果你是一家想实现下一个更大目标的公司，你应该乐于付出合理的开销，以神奇的方式消除团队中容易出错且耗时的过程。

使用现成的Terraform工具，你还可以通过简单的单行更改创建一个可以扩展的集群。在我的上一个团队，我们仅仅通过将Git提交命令从2改到4，就将集群从2个节点增长到了四个节点。添加节点后，Kubernetes会自动将资源移动到新的节点上，不需要进一步的工作。然后你可以继续解决工作中的实际问题。

传统的Linux生产系统通常看起来像这样：你有一些用Java，Python或Ruby编写的代码。应用程序代码通常由不太了解服务器的人编写（或者至少没有服务器的实践经验）。

假设你有一台机器在阿里云ECS中，由你的运营团队中的某人管理，该人不太了解应用程序代码。当应用程序团队完成某些工作时，他们希望能够部署这些更改。运维团队希望确保所做的更改不会破坏任何系统的内容。

你也不希望系统在部署期间离线。如果出现问题，你希望能够回滚到以前的代码版本。从上载资产到启动服务器的部署过程需要30分钟怎么办？难道要将系统离线30分钟吗？可能不会。你可能会想出一些系统来保持版本n-1的运行，直到版本n启动为止，此时你将切换到新版本。

这听起来确实有点复杂，有很多要记住的地方，还有很多可能出错的地方。这些部署规则会用一系列脚本进行编写，这些脚本需要进行版本控制和维护，并且很可能本身包含错误。而且，当我们将公司扩展为各个独立的团队时，他们所有人都可能一天多次部署。然后噩梦就开始了。运维团队开始对系统中的客户流失感到不知所措。随着过程变得越来越繁琐，部署花费的时间也越来越长。

这个故事听起来很熟悉吗？

Kubernetes消除了很多复杂性。要部署新版本的服务，我们可以简单地更新容器镜像以指向新版本的代码。我们还可以定义运行状况检查，以在宣布新版本正常运行之前执行该检查。如果未通过，则旧版本的代码将继续运行 。

我们可以使用仅供内部使用的DNS名称（例如order_service）定义服务，该名称将自动平衡正在运行的副本的负载。无需维护运行实例的列表。并且，如果我们在部署后发现问题，则可以使用简单的回滚命令查找先前的容器镜像并将其应用。通常这只需要几秒钟，然后我们回到运行软件的最新已知稳定版本。

听起来不是很好吗？

我在一些复杂的系统上工作过，这些系统要求管理部署的人员了解a)Python，b)Bash，c）我们正在运行的OS版本的一些细微差别，d）JVM标志，e） SCP命令（您可以在不查看文档的情况下编写有效的SCP命令吗？）……等等。

还有一些组织开销。部署脚本和基础结构代码通常由运维团队管理。但是开发人员经常需要更改部署代码，例如，在启动时设置标志，并扩大系统规模。这在开发人员和 *** 作人员之间造成了紧张关系，因为这两个团队之间产生了彼此的要求，但往往会遵循不同的目标。

所有的这些复杂性会增加你在启动过程中的开销。如果你想快速开发新功能并且能够轻松地从一个项目跳到另一个项目，想保持尽可能小的摩擦。那么Kubernetes消除了很多痛苦，让你专注于产品。

当然这个世界上没有灵丹妙药，而且在某些情况下，像Kubernetes这样的东西有点过于庞大。

如果你只是运行WordPress，则不需要Kubernetes。如果你运行的CMS只是偶尔进行一次升级，升级库或安装插件，而实际上从未真正部署过，则不需要Kubernetes。Kubernetes确实是针对管理大型，不断变化的系统进行了优化。

显然，如果你要编写需要与Linux内核接口的底层嵌入式系统或软件，那么Kubernetes不适合你。这适用于任何容器化解决方案。

Kubernetes确实有一种称为“状态集”的资源类型，旨在运行诸如数据库和管理状态的消息代理之类的东西。从理论上讲，运行有状态集可以允许您运行多个副本并上下缩放它们，以及附加和扩展存储。但是这样做总是让我有些紧张。借助应用程序服务，我希望使开发人员可以轻松调整设置和部署，而不会遇到麻烦。对于数据库，反而相反。因为意外更改设置或将系统升级到新版本比较少见。我也不想让我的数据库在集群中争夺CPU和内存。

如果我使用的是阿里云并且可以访问RDS，那么我特别倾向于不使用Kubernetes来存储数据库。你选择的云提供商中的RDS或类似产品将更易于管理自动备份，扩展和监控。

Kubernetes非常适合需要随时间扩展和增长的任何项目 。

如果你是一家初创公司，那么几乎可以肯定你属于该类别。你现在可能很小，但是你在不断成长。这就是你说服投资者的理由，也是你聘请如此多开发人员的原因。你的系统将要快速更改和扩展，因此你希望以尽可能减少成本和摩擦的方式构建系统。

仅出于这个原因，我认为任何电子商务，SaaS或类似公司尽早投资Kubernetes都是有意义的。即使你只是在集群中部署单个简单的Web应用程序，对未来进行规划也意味着精心构建基础架构，以使你的团队能够快速移动一年或三年。

---