【CKA考试笔记】二、kubernetes介绍及部署

为什么要使用kubernetes？

（1）在使用docker或nerdctl创建容器时，都需要手动使用run命令去创建，那么假如生产环境中需要创建成千上万个容器时，手动创建就会大大影响效率

（2）若某台服务器宕机了，那么里面的容器也停止了，不具备高可用性

（3）若某个容器出现了问题，很难被发现，不便于管理

——所以为了更方便地管理容器，我们使用容器编排工具来对容器进行统一管理，kubernetes就是一种容器编排工具，除此之外还有：
docker swarm
mesos
openshift
…

有了k8s，就不需要我们一个一个手动创建了，k8s会帮我们去管理容器，k8s通过一个代理——kubelet，通过kubelet去访问一个个runtime（docker、containerd、rkt、cri-o…），从而进行管理容器，原先docker一家独大，但是随着各种容器客户端的发展，都想接入k8s作为runtime，但是若将每一个客户端产品都加进k8s，非常不利于维护，因此k8s制定了一个标准接口（CRI），只要符合这个标准，并提供CRI-shim（垫片，支持CRI标准的runtime），就可以接入k8s作为runtime，并且使用gPRC协议来互相通信

由于docker不支持CRI标准，因此1.24版本之后的k8s不支持docker，若还是想使用docker，则可以在中间增加一个转接头：cri-docker

kubernetes架构及组件介绍

以VMware的虚拟化架构来举例

如图，ESXi是专门用来运行虚拟机的，为了统一管理、统一调度这些ESXi及里面的虚拟机，需要安装一台vcenter，来作为一个控制台，通过 vsphere client 或 vsphere web client 连接到vcenter上，来对整个虚拟化架构进行管理

k8s的架构就类似这种虚拟化架构类似

master（控制台）——就相当于vcenter作为一个控制台，也称 control plane node（控制平面节点）
worker（节点）——就相当于ESXi，专门用于运行pod

pod（豆荚）
在docker、nerdctl中，直接管理容器，容器是最小的调度单位，而在k8s中，直接管理的是pod，pod是最小的调度单位，pod与容器的关系就好比豆荚与豆子的关系，pod是豆荚，容器就是豆荚里一粒粒的豆子，而kubernetes就好比豆荚藤

一个pod里可以有多个容器，但一般我们只会在一个pod里设计一个容器，那既然只有一个容器，为什么还要在外面加个pod这层壳呢，因为在pod里有各种策略、各种网络设置，加强了功能

kubernetes中的组件
master上运行的组件
kubectl：客户端命令行工具，为整个系统的操作入口，将命令发送给api-server
api-server：REST接口，接收客户端请求，为整个系统的控制入口
scheduler：调度器，节点资源管理，创建pod时，判断并分配到某个worker来创建
controller-manager：整个系统的大管家，执行整个系统中的后台任务，监控节点状况、pod个数、pod和service的关联等
kubelet：运行在master和每个节点上，作为代理，接受master分配过来的任务，周期性获取容器状态，反馈给master上的api-server
kube-proxy：运行在master和每个节点上，作为代理，用于把发送给service的请求转发给后端pod，做相应策略，模式有iptables和ipvs

worker上运行的组件
kubelet：略
kube-proxy：略
calico网络：使得各个节点中的pod能够互相通信，集群安装好一定要安装这个组件，docker都是在单机上配置的，不同主机若想要通信，一是通过端口映射，要不就是安装calico网络来实现，k8s是多主机的环境，pod可能分布在各个不同的机器上，因此各个pod若想互相通信，则需要在k8s环境中安装calico网络

（docker中我们手动run命令来创建容器，k8s中，客户端连接到master，发出一个创建pod请求，master里的调度器来判定由worker来创建）
——api-server接收用户请求，验证用户身份、权限，当接收到了创建pod请求，就会通过scheduler来调度由哪个节点来创建，当然也可以自己指定，每个节点上都有一个kubelet，kubelet中可以进行一些配置，如使用哪个厂商的runtime（containerd、docker…）、kubelet接收到了创建pod请求后，调用相应的runtime去创建容器，每一次kubelet与api-server的通信，都需要TLS证书认证，controller-manager是整个系统的大管家，会实时监控系统运行状态，当监测到kubelet证书过期了，controller-manager会重新给它颁发证书，当监测到某个pod宕机了，会重新生成一个这样的pod，但是pod的IP地址会改变， 因此用户直接访问这个pod并不方便，所以设置了一个service-svc的服务，它实际上实现了负载均衡的功能，用户访问service-sve，然后由service-sve通过kube-proxy这个组件来转发到后端的pod，转发时kube-proxy通过iptables或者ipvs这两种模式来实现
——可以通过BGP、vxlan、openswitch等技术在各个节点之间建立通道，例如calico工具封装了这些协议，使得各个节点内的pod可以跨节点通信
——用户所有的创建、删除等操作及一些配置信息，都会记录到etcd数据库里去

安装K8S集群环境

前置准备（所有节点上都需要操作）

实验中准备3台centos虚拟机，一台作为master（192.168.26.21），两台作为worker（192.168.26.22、192.168.26.23）

以下为所有节点上都需要操作的步骤：

（1）同步/etc/hosts，使所有节点都能互相解析

#1.编辑/etc/hosts文件
vim /etc/hosts
#2.都同步为如下
192.168.26.21 vms21.rhce.cc vms21
192.168.26.22 vms22.rhce.cc vms22
192.168.26.23 vms23.rhce.cc vms23
#修改好master上的后，可以拷贝到其他节点上
scp /etc/hosts vms22:/etc
scp /etc/hosts vms23:/etc

（2）所有节点关闭selin