实验环境
安装好k8s集群
一、kubernetes组件构成
1、架构图
2、组件介绍
使用以下命令查看相关资源
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 调度进行工作的。
主要几个组件的作用以及架构工作流程：
kubectl发送部署请求到API server。
APIserver通知Controller Manager 创建一个控制资源（如Deployment任务）。
Scheduler执行调度任务，将副本Pod创建任务分发到node上。
node上的kubelet在各自节点上创建并运行Pod。
用户通过kube-proxy访问到服务资源。
（1）kubectl
k8s是命令行端，用来发送用户的操作指令。
（2）API server
是k8s 集群的前端接口，各种客户端工具以及k8s的其他组件可以通过它管理k8s集群的各种资源。是所有服务访问的统一入口。
（3）Scheduler
负责决定将Pod放在哪个Node上运行。在调度时，会充分考虑集群的拓扑结构，当前各个节点的负载情况，以及应对高可用、性能、数据亲和性和需求。
负责接收任务，选择合适的节点进行分配任务。
（4）Controller Manager
负责管理集群的各种资源，保证资源处于预期的状态，用来维持副本期望数量。
它由多种Controller 组成，包括Replication Controller维护副本数量即期望值，创建删除pod、Endpoints Controller、Namespace Controller、Serviceaccounts Controller等等。
（5）Etcd
键值对数据库 ，存储k8s集群所有重要信息（持久化），负责保存k8s集群的配置信息和各种资源的状态信息。当数据发生变化时，etcd会快速的通知k8s相关组件。
第三方组件，它有可替换方案 Consul、zookeeper。
（6）Kubelet
它是Node上的agent(代理)，接受调度，管理pod。当Scheduler确定某个Node上运行Pod之后，会将Pod的具体配置信息发送给该节点的kubelet,kubelet会根据这些信息创建和运行容器，并向Master报告运行状态。
管理(增删改查)Pod
（7）kube-proxy
服务发现和负载均衡，负责将访问service的TCP/UDP数据流转发到后端的容器（转发数据流，反向代理，多个pod副本，就会实现负载均衡）
（8）COREDNS
可以为集群中的SVC创建一个域名IP的对应关系解析
（9）DASEBORD
给k8s提供一个B/S结构的UI界面（仪表盘）。
（10）INGRESS Crontroller
官方只能实现4层负载均衡，它可以实现7层负载均衡。
（11）Pod
k8s集群的最小组成单位。一个Pod内，可以运行一个或多个容器，通常关系紧密的几个容器部署在同一个pod中。
大多数情况下，一个Pod内只有一个Container容器。
如需在运行的Pod中生成新的容器，可在pod定义文件中修改，端口不能相同.
（12）Flannel/Calico
是k8s集群网络方案，可以保证Pod的跨主机通信。第三方解决方案，也有替换方案。
二、区分Pod与Deployment
运行例子区分Pod与Deployment
1、创建一个名为 test-web 的 Pod，使用 nginx:1.20 镜像
kubectl run test-web --image=nginx:1.20
将 test-web Pod 暴露为一个 Service，端口为 80，类型为 NodePort
该 Service 会将 Pod 的 80 端口暴露到集群节点的某个端口（随机分配）
kubectl expose pod test-web --port=80 --type=NodePort
获取当前命名空间下的 Deployment、Pod 和 Service 的详细信息
kubectl get deployment,pod,svc -o wide
-o wide：显示更详细的信息
2、创建一个名为 nginx 的 Deployment，使用 nginx:1.20 镜像
kubectl create deployment nginx --image=nginx:1.20
将 nginx Deployment 暴露为一个 Service，端口为 80，类型为 NodePort
kubectl expose deployment nginx --port=80 --type=NodePort
将 nginx Deployment 的 Pod 副本数扩展到 4 个
kubectl scale deployment nginx --replicas=4
获取当前命名空间下的 Deployment、Pod、Service 和 ReplicaSet 的详细信息
kubectl get deployment,pod,svc,rs -o wide
3、删除名为 test-web 的Pod
kubectl delete pod test-web
查看集群中所有Pod的详细信息
kubectl get pod -o wide
如果该 Pod 不是由 Deployment 或 ReplicaSet 管理的，则不会被自动重建
4、删除nginx服务的一个pod
kubectl delete pod nginx-5cfbb5c9f4-h4bks
如果该 Pod 是由 Deployment 或 ReplicaSet 管理的，Kubernetes 会自动创建一个新的 Pod 来替换被删除的 Pod
5、删除名为 nginx 的 Deployment
kubectl delete deployment nginx
查看集群中所有Deployment的详细信息
kubectl get deployment -o wide
由该 Deployment 管理的所有 Pod 和 ReplicaSet 也会被自动删除
6、删除名为 nginx 和test-web的 Service（删除 Service 会清除相关的网络配置）
kubectl delete service nginx
kubectl delete service test-web
查看集群中所有Service的详细信息
kubectl get svc -o wide
总结：
1、Deployment是Pod资源管理器，负责控制Pod预期副本数量
2、Pod是集群中的最小管理单元，负责管理容器，可以受资源管理器控制，也可以单独运行
3、Service是对pod的代理，pod可能会发生变化，但service是不变的，service负责跟踪pod的变化
三、常见的Pod控制器类型
1、ReplicationController
RC用于确保每个Pod副本在任意时刻都能满足目标数量，简单点来说，它用于保证每个容器或容器组总是运行并且可以访问的：老一代无状态的Pod应用控制器。
2、ReplicaSet
RS新一代的无状态的Pod应用控制器，它与RC的不同之处在于支持的标签选择器不同，RC只支持等值选择器，RS还额外支持基于集合的选择器。
3、Deployment
为Pod和Replicaset提供了一个声明式定义（declarative）方法，
Deployment是通过调用ReplicaSet来实现对pod管理的。
典型的应用场景：
定义Deployment来创建ReplicaSet和Pod
滚动升级和回滚应用
扩容和缩容
4、DaemonSet
用于确保每一个节点都运行了某个Pod的一个副本，新增的节点一样会被添加此类Pod,在节点移除时，此类Pod会被回收。
典型的应用场景：
在node上运行日志收集
在node上运行监控
5、StatefulSet
用于管理有状态的持久化应用，如database服务程序，它与Deployment不同之处在于，它会为每一个Pod创建一个独有的持久性标识符，并确保每个Pod之间的顺序性。
典型的应用场景：
稳定的持久化存储
稳定的网络标志
有序部署，有序扩展
有序收缩，有序删除
补充：服务分类
有状态服务：DBMS数据库管理系统(MYSQL)从pod中剔除后，再恢复就会造成数据丢失。
无状态服务：LVS APACHE NGINX
6、Job
用于管理运行完成后即可终止的应用，例如批量处理作业任务，保证一次性任务pod成功结束。
7、Cronjob
管理基于时间的job，即：
在给定的时间点只运行一次
周期性地在给定时间点运行
8、Horizontal Pod Autoscaling
应用的资源使用率通常都有高峰和低谷，削峰填谷，提高集群的整体资源利用率，让service的pod个数自动调整，使pod水平自动缩放。
总结：
无状态应用：使用 Deployment。
有状态应用：使用 StatefulSet。
节点级别任务：使用 DaemonSet。
一次性任务：使用 Job。
周期性任务：使用 CronJob。
四、k8s集群中的个ip、端口区分
1、Master节点群集初始化参数解析
kubeadm init --kubernetes-version=v1.28.2 --pod-network-cidr=10.244.0.0/16 --apiserver-advertise-address=192.168.10.11 --cri-socket unix:///var/run/cri-dockerd.sock
--pod-network-cidr=10.244.0.0/16 指定 Pod 网络的 CIDR 范围（10.244.0.0/16）（即pod/容器的IP 地址，群集内访问使用）
--apiserver-advertise-address=192.168.10.11 指定主节点的 IP 地址，其他节点将通过这个地址访问 API Server（即物理网卡的 IP 地址，外部访问使用）
--service-cidr=10.96.0.0/12 指定集群中 Service 的 IP 地址范围（CIDR）（即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
获取当前命名空间下的 Deployment、Pod、Service 的详细信息
kubectl get deploy,pod,svc -o wide
输出字段说明：
Deployment
NAME：Deployment 的名称。
READY：当前 Ready 的 Pod 数量 / 期望的 Pod 数量。
UP-TO-DATE：已更新到最新版本的 Pod 数量。
AVAILABLE：当前可用的 Pod 数量。
AGE：Deployment 的创建时间。
CONTAINERS：Deployment 中容器的名称。
IMAGES：容器使用的镜像。
SELECTOR：用于选择 Pod 的标签。
Pod
NAME：Pod 的名称。
READY：Pod 中 Ready 的容器数量 / 总容器数量。
STATUS：Pod 的当前状态（如 Running、Pending、Failed 等）。
RESTARTS：容器重启的次数。
AGE：Pod 的创建时间。
IP：Pod 的 IP 地址。
NODE：Pod 所在的节点名称。
Service
NAME：Service 的名称。
TYPE：Service 的类型（如 ClusterIP、NodePort、LoadBalancer）。
CLUSTER-IP：Service 的 ClusterIP 地址。
EXTERNAL-IP：Service 的外部 IP 地址（如果有）。
PORT(S)：Service 暴露的端口。
AGE：Service 的创建时间。
SELECTOR：用于选择 Pod 的标签。
查看名为 nginx3 的 Service 的详细信息
kubectl describe service nginx3
使用浏览器访问
192.168.10.11:31714
端口为对外暴露端口
