Kubernetes架构介绍

• kubernetes组件构成：

1. 1. 架构图：

1. 1. 组件介绍：

通过以下命令查看相关资源：

kubectl get nodes                                     #查看群集节点

kubectl get ns                                            #查看名称空间

kubectl get pod -A                                    #查看所有命名空间中的pod

kubectl get pod -n kube-system              #查看kube-system名称空间中的pod

kubectl get pod -n calico-system             #查看calico-system名称空间中的pod

systemctl status kubelet                           #查看kubelet服务的状态

Kubernetes群集分为Master 和node 节点，

master 是调度分配任务的，

node 实际接受master 调度进行工作的，

主要几个组件的作用以及架构工作流程：

1. kubectl发送部署请求到API server
2. APIserver通知Controller Manager 创建一个控制资源（如Deployment任务）。
3. Scheduler执行调度任务，将副本Pod创建任务分发到node上。
4. node上的kubelet在各自节点上创建并运行Pod。
5. 用户通过kube-proxy访问到服务资源。

1. 1. 1. kubectl:

k8s是命令行端，用来发送用户的操作指令。

1. 1. 1. API server:

是k8s 集群的前端接口，各种客户端工具以及k8s的其他组件可以通过它管理k8s集群的各种资源。是所有服务访问的统一入口。

1. 1. 1. Scheduler:

负责决定将Pod放在哪个Node上运行。在调度时，会充分考虑集群的拓扑结构，当前各个节点的负载情况，以及应对高可用、性能、数据亲和性和需求。

负责接收任务，选择合适的节点进行分配任务。

1. 1. 1. Controller Manager:

负责管理集群的各种资源，保证资源处于预期的状态，用来维持副本期望数量。

它由多种Controller 组成，包括Replication Controller维护副本数量即期望值，创建删除pod、Endpoints Controller、Namespace Controller、Serviceaccounts Controller等等。

1. 1. 1. Etcd:

键值对数据库 ，存储k8s集群所有重要信息（持久化），负责保存k8s集群的配置信息和各种资源的状态信息。当数据发生变化时，etcd会快速的通知k8s相关组件。

        第三方组件，它有可替换方案 Consul、zookeeper。

1. 1. 1. Kubelet:

它是Node上的agent(代理)，接受调度，管理pod

当Scheduler确定某个Node上运行Pod之后，会将Pod的具体配置信息发送给该节点的kubelet,kubelet会根据这些信息创建和运行容器，并向Master报告运行状态。

管理(增删改查)Pod.

1. 1. 1. kube-proxy:

服务发现和负载均衡，负责将访问service的TCP/UDP数据流转发到后端的容器

（转发数据流，反向代理，多个pod副本，就会实现负载均衡）

1. 1. 1. COREDNS:

可以为集群中的SVC创建一个域名IP的对应关系解析

1. 1. 1. DASEBORD:

给k8s提供一个B/S结构的UI界面（仪表盘）。

1. 1. 1. INGRESS Crontroller：

官方只能实现4层负载均衡，它可以实现7层负载均衡。

1. 1. 1. Pod：

k8s集群的最小组成单位。一个Pod内，可以运行一个或多个容器，通常关系紧密的几个容器部署在同一个pod中。

        大多数情况下，一个Pod内只有一个Container容器。

        如需在运行的Pod中生成新的容器，可在pod定义文件中修改，端口不能相同

1. 1. 1. Flannel/Calico:

是k8s集群网络方案，可以保证Pod的跨主机通信。第三方解决方案，也有替换方案。

• 区分Pod与Deployment

运行一个例子（区分一下pod与deployment）：

//创建一个pod

kubectl run test-web --image=nginx:1.20

kubectl expose pod test-web --port=80 --type=NodePort

kubectl get deployment,pod,svc -o wide

//创建一个deployment

kubectl create deployment nginx --image=nginx:1.20

kubectl expose deployment nginx --port=80 --type=NodePort

kubectl scale deployment nginx --replicas=4

kubectl get deployment,pod,svc,rs -o wide

 //删除pod和deployment，查看验证

kubectl delete pod nginx-f54648c68-52v8

kubectl delete pod test-web

kubectl delete deployment nginx

kubectl delete service nginx

kubectl delete service test-web

总结：

1. Deployment是Pod资源管理器，负责控制Pod预期副本数量
2. Pod是集群中的最小管理单元，负责管理容器，可以受资源管理器控制，也可以单独运行
3. Service是对pod的代理，pod可能会发生变化，但service是不变的，service负责跟踪pod的变化

• 常见的pod控制器类型

查看pod使用的控制器：

kubectl describe pod      pod名称

1. 1. ReplicationController:

RC用于确保每个Pod副本在任意时刻都能满足目标数量，简单点来说，它用于保证每个容器或容器组总是运行并且可以访问的：老一代无状态的Pod应用控制器。

1. 1. ReplicaSet:

RS新一代的无状态的Pod应用控制器，它与RC的不同之处在于支持的标签选择器不同，RC只支持等值选择器，RS还额外支持基于集合的选择器。

1. 1. Deployment:

为Pod和Replicaset提供了一个声明式定义（declarative）方法，

Deployment是通过调用ReplicaSet来实现对pod管理的。

典型的应用场景：

定义Deployment来创建ReplicaSet和Pod

滚动升级和回滚应用

扩容和缩容

1. 1. DaemonSet:

用于确保每一个节点都运行了某个Pod的一个副本，新增的节点一样会被添加此类Pod,在节点移除时，此类Pod会被回收。

   

典型的应用场景：

        在node上运行日志收集

        在node上运行监控

1. 1. StatefulSet: 

用于管理有状态的持久化应用，如database服务程序，它与Deployment不同之处在于，它会为每一个Pod创建一个独有的持久性标识符，并确保每个Pod之间的顺序性。

       

典型的应用场景：

        稳定的持久化存储

        稳定的网络标志

        有序部署，有序扩展

        有序收缩，有序删除

----------------------------------------------------------------------

补充：服务分类

           有状态服务：DBMS数据库管理系统(MYSQL)从pod中剔除后，再恢复就会造成数据丢失。

           无状态服务：LVS APACHE NGINX

---------------------------------------------------------------------

1. 1. Job:

用于管理运行完成后即可终止的应用，例如批量处理作业任务，保证一次性任务pod成功结束。

1. 1. Cronjob：

管理基于时间的job，即：     

        在给定的时间点只运行一次

        周期性地在给定时间点运行

1. 1. Horizontal Pod Autoscaling:

应用的资源使用率通常都有高峰和低谷，削峰填谷，提高集群的整体资源利用率，让service的pod个数自动调整，使pod水平自动缩放。

==========================================

• k8s集群中的各ip、端口区分：

1. 1. Master节点群集初始化参数解析：

kubeadm init --kubernetes-version=v1.28.2 --pod-network-cidr=10.244.0.0/16  --service-cidr=10.96.0.0/12 --apiserver-advertise-address=192.168.10.11  --cri-socket unix:///var/run/cri-dockerd.sock

---------------------------------------------------

NodeIP：         节点IP地址（即物理网卡的 IP 地址，外部访问使用）

PodIP：           PodIP 地址（即pod/容器的IP 地址，群集内访问使用）

ClusterIP          群集IP地址（即Service 的 IP 地址，此为虚拟 IP 地址，群集内访问使用）

---------------------------------------------------

●port

port是k8s集群内部访问service的端口，即通过clusterIP: port可以从Pod所在的Node. 上访问到service

●nodePort

nodePort是外部访问k8s集群中service的端口，通过nodeIP: nodePort 可以从外部访问到某个service。

●targetPort

targetPort是Pod的端口，从port或nodePort来的流量经过kube-proxy 反向代理负载均衡转发到后端Pod的targetPort上，最后进入容器。

●containerPort

containerPort是Pod内部容器的端口，targetPort 映射到containerPort

结论：port和nodePort都是service的端口，port暴露给k8s集群内部服务访问，nodePort暴露给k8s集群外部流量访问；

        从port和nodePort两个端口过来的数据都需要经过反向代理kube-proxy，流入后端pod的targetPort上，最后到达pod内的容器端口

-----------------------------------------------------

创建pod资源：

kubectl create deployment nginx3 --image=nginx:1.20

kubectl expose deployment  nginx3 --port=80 --type=NodePort

查看命令：

kubectl get deploy,pod,svc -o wide （kubectl get all -o wide）

kubectl describe service 服务名称

[root@master ~]# kubectl describe service nginx3

Name:                     nginx3

Namespace:                default

Labels:                   app=nginx3

Annotations:              <none>

Selector:                 app=nginx3

Type:                     NodePort

IP:                       10.102.200.216                             #群集IP，群集内访问

Port:                     <unset>  80/TCP                           #群集port，群集内访问

TargetPort:               80/TCP                                              #TargetPort: pod端口

NodePort:                 <unset>  31209/TCP                   #NodePort:外部访问端口

Endpoints:                10.244.2.9:80                                   #pod/容器ip:端口

Session Affinity:         None

External Traffic Policy:  Cluster

Events:                   <none>