kubernetes 使用1.31.1 版本搭建集群核心组件，选择flannel 网络插件为整体集群的运行提供网络通信功能。
flannel 网络插件
kube-flannel kube-flannel-ds-9fgml 1/1 Running 1 (18m ago) 2d21h
kube-flannel kube-flannel-ds-ghwbq 1/1 Running 1 (18m ago) 2d21h
kube-flannel kube-flannel-ds-mkm4r 1/1 Running 1 (18m ago) 2d21h
K8S核心组件：
1、coredns提供集群内的DNS解析
kube-system coredns-fcd6c9c4-cvcvt 1/1 Running 1 (18m ago) 2d21h
kube-system coredns-fcd6c9c4-m9kxk 1/1 Running 1 (18m ago) 2d21h
2、ectd (基于键值对的数据库) 提供集群数据的存储（1） pod的名称数量（2）网络参数的分配（3）集群的状态
kube-system etcd-control 1/1 Running 1 (18m ago) 2d21h
3、api-server：Kubernetes的api响应服务器，用户向K8S平台发出的所有指令，都是先给到api-server，由APIserver 根据用户的请求以调用不同的组件
kube-system kube-apiserver-control 1/1 Running 1 (18m ago) 2d21h
4、controller-manager：完成pod的启动和状态维护，比如pod停止了，由controller-manager 完成pod的重启
kube-system kube-controller-manager-control 1/1 Running 1 (18m ago) 2d21h
5、kube-proxy：K8s的代理服务
kube-system kube-proxy-54j4f 1/1 Running 1 (18m ago) 2d21h
kube-system kube-proxy-c8cdj 1/1 Running 1 (18m ago) 2d21h
kube-system kube-proxy-v7td8 1/1 Running 1 (18m ago) 2d21h
6、scheduler-control: 调度管理器，决定K8S中运行pod的节点，指定pod的运行节点。
kube-system kube-scheduler-control 1/1 Running 1 (18m ago) 2d21h
pod
pod 是K8S平台上最小的管理单位，pod是K8S平台上运行的进程。
什么是容器？应用容器化的本质是什么？
容器是一个隔离的沙盒环境。容器实现隔离环境所使用的技术是namespace （名称空间）cgroup （控制组）。沙盒环境中包括了运行某一个应用所需要的基本依赖关系和运行的环境（配置文件、日志输出、启动程序等）。一个应用的镜像包括了应用运行所需要的所有的依赖管理和运行环境的支持。应用容器化的本质分为两步：1.将应用运行需要的所有文件打包，制作镜像2. 将镜像中的程序启动（运行起来），程序运行起来之后，就是进程了，换一句叫做运行容器，或者跑一个容器。
总结一下： 容器实际就是在操作系统上使用软件技术隔离一个环境，然后运行程序的过程。所以在容器宿主机上，在容器内部只能看到容器内部启动的进程，举个例子：容器中通常有一个pid为1 的进程，而这个进程不是容器宿主机中pid为1 的进程，容器宿主机中可以看到容器启动的进程，但是并不知道容器具体使用哪个程序启动对应的进程。
pod的重点类似于容器，也是需要在一个相对隔离的环境下启动进程，并为隔离环境中的进程提供需要的网络、存储等资源的访问。但是pod并不是容器，pod提供容器所需要的隔离环境，并为隔离环境内的容器提供必要的网络和存储，所以某种程度上pod 是用来管理容器的上一级概念。
在K8S中，一个pod=一个运行中的应用实例
pod运行容器的方式：
- 一个pod中封装一个容器，最简单的运行方式，但是如果需要较为复杂架构的实现，还是需要较为复杂的配置过程。
- 一个pod中封装多个容器：可以直接在一个pod中运行所有的服务，比如说lamp等常见组合，另一个原因在于同一个pod中的容器直接基于localhost进行通信，也不需要复杂的网络配置或者繁琐的数据同步。
K8S 资源对象：
-
pod （最小调度单位，一定属于某一个名称空间）
- K8S 的名称空间，一般是为了给不同的项目进行项目环境的隔离而使用的概念，
- 类比ansible不同的目录可以代表不同的项目代码，Ｋ８Ｓ不同的名称空间运行不同的应用
-
node （K8S工作节点，应用pod一般都运行在工作节点上，node 不属于任何名称空间，同样持久卷也不属于任何名称空间）
[root@control ~]# kubectl get nodes // 列出节点信息
NAME STATUS ROLES AGE VERSION
control Ready control-plane 3d4h v1.31.1
node1 Ready <none> 3d4h v1.31.1
node2 Ready <none> 3d4h v1.31.1
[root@control ~]# kubectl get nodes -o wide // 列出所有节点基本信息
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
control Ready control-plane 3d4h v1.31.1 192.168.110.10 <none> CentOS Stream 9 5.14.0-474.el9.x86_64 containerd://1.7.22
node1 Ready <none> 3d4h v1.31.1 192.168.110.11 <none> CentOS Stream 9 5.14.0-474.el9.x86_64 containerd://1.7.22
node2 Ready <none> 3d4h v1.31.1 192.168.110.22 <none> CentOS Stream 9 5.14.0-474.el9.x86_64 containerd://1.7.22
[root@control ~]# kubectl describe node control // 列出指定节点的详细信息
以相对动态的方式实时获取每一个节点的基本信息，使用一个K8S的组件 metrics-server 来收集每一个节点的内存CPU 等资源的实时使用率，metrics-server将在api-server 中增加关于节点状态收集的api路径，收集到的节点信息可以传递给其他的监控软件使用。
[root@control ~]# wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
[root@control ~]# cat .kube/registry_cn
registry.cn-hangzhou.aliyuncs.com/google_containers/
[root@control ~]# mv components.yaml metrics-server.yml
mv: overwrite 'metrics-server.yml'? y
[root@control ~]# vim metrics-server.yml
[root@control ~]# kubectl apply -f metrics-server.yml
serviceaccount/metrics-server created
clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
clusterrole.rbac.authorization.k8s.io/system:metrics-server created
rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created
clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created
clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created
service/metrics-server created
deployment.apps/metrics-server created
apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created
[root@control ~]# kubectl get pods -o wide -n kube-system
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
coredns-fcd6c9c4-cvcvt 1/1 Running 1 (6h52m ago) 3d4h 10.244.1.10 node1 <none> <none>
coredns-fcd6c9c4-m9kxk 1/1 Running 1 (6h52m ago) 3d4h 10.244.1.9 node1 <none> <none>
etcd-control 1/1 Running 1 (6h52m ago) 3d4h 192.168.110.10 control <none> <none>
kube-apiserver-control 1/1 Running 1 (6h52m ago) 3d4h 192.168.110.10 control <none> <none>
kube-controller-manager-control 1/1 Running 1 (6h52m ago) 3d4h 192.168.110.10 control <none> <none>
kube-proxy-54j4f 1/1 Running 1 (6h52m ago) 3d4h 192.168.110.11 node1 <none> <none>
kube-proxy-c8cdj 1/1 Running 1 (6h52m ago) 3d4h 192.168.110.10 control <none> <none>
kube-proxy-v7td8 1/1 Running 1 (6h52m ago) 3d4h 192.168.110.22 node2 <none> <none>
kube-scheduler-control 1/1 Running 1 (6h52m ago) 3d4h 192.168.110.10 control <none> <none>
metrics-server-86c648b4bf-tfhjp 1/1 Running 0 50s 10.244.2.10 node2 <none> <none>
实时监控节点的资源使用情况：
[root@control ~]# kubectl top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
control 170m 8% 1636Mi 43%
node1 60m 3% 1109Mi 29%
node2 47m 2% 1019Mi 13%对于K8S集群中的工作节点的增加和移除：
增加新的工作节点：
- 配置工作节点的OCI 、selinux等基础环境
- kubeadm join 命令加入到K8S 现有集群中
移除工作节点：
禁止向指定节点调度新的pod
kubectl cordon node 节点名
移除在指定节点上的pod
kubectl drain node 节点名
以上这两步也可以将指定的工作节点进行常规的状态维护
结束常规的技术维护之后，重新加入K8S调度的指令：
kubectl uncordon node 节点名
3、namespace 和用来进行容器环境隔离的namesapce 不是一个层面的东西
kubectl get //列出指定的资源类型
kubectl get pods // 列出所有的pod资源
kubectl get nodes // 列出所有的节点信息
kubectl get namespace // 所有的名称空间
[root@control ~]# kubectl get ns
NAME STATUS AGE
default Active 3d4h // 本身默认的名称空间
kube-flannel Active 3d4h // 创建flannel 网络插件时，创建的专门用于运行网络插件的名称空间
kube-node-lease Active 3d4h // 管理K8S集群节点有限期，属于默认名称空间
kube-public Active 3d4h // 也属于默认的名称空间
kube-system Active 3d4h // 默认名称空间，K8S核心组件资源4、label 标签/ annotation 备注
5、taint 污点 toleration 容忍
taint 一般设置在工作节点，用来说明节点的一些不适合运行pod的状态
toleration 一般设置在某个pod上，用来说明可以调度到条件适配的有污点的节点。
6、Service // 使用pod运行的应用一个会认为是一个独立的服务
7、Volume // 卷 pod 使用的存储
8、PersistentVolume // 持久卷
9、Deployment // 服务部署 一次需要调度的pod的数量
10、Secret // K8s 加密数据的访问
11、StatefulSet // 有状态的服务部署 网络资源固定分配以及存储资源的持久化
12、DaemonSet // 无状态的服务部署
13、ServiceAccount // 服务装好
14、ReplicationController // 副本控制器
15、ReplicaSet // 副本集控制器，和上一条功能相同 只是版本不同
16、Job // 一个定时作业
17、CronJob // 一个周期作业
18、SecurityContext // 安全上下文
19、ResourceQuota // 资源配额 容器资源限制
20、LimitRange // 范围限制
21、HorizontalPodAutoscaling // pod水平扩展 一般通过RC RS等资源快速实现
22、Ingress // 集成的应用网关，属于一种网络和应用功能的合并资源
23、ConfigMap // 配置映射，一般用来解决卷和持久卷的映射关系
24、Role // 用来进行用户权限约束的资源 K8S平台中不是通过属主属组进行权限划分，而是通过角色划分用户的权限
25、ClusterRole // 对K8S集群本身管理权限的划分
练习参考资料：
https://kubernetes.io/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/部署一个无状态应用到K8S集群
-
目前对于无状态应用的部署通过deployment实现，创建一个deployment 会自动选择RS控制器，创建应用副本数量的控制器。
-
rc 作为一种较早的副本控制器，已经不推荐再继续使用
-
K8S中的资源不直接通过create 子命令创建，为了更加贴合应用的实际运行环境，K8S对于大部分管理资源的创建都是通过一种叫做声明式配置的文件进行预先配置，然后进行创建。
[root@control ~]# vim nginx-deployment.yml
apiVersion: apps/v1 //K8Sapiserver的路径
kind: Deployment //资源类型 Deployment
metadata: //针对资源的元数据
name: nginx-deployment // 设置资源的名称
spec: // 资源具体的参数
selector: // 选择器
matchLabels: // 匹配标签的值
app: nginx // 设定的值
replicas: 2 // 告知 Deployment 运行 2 个与该模板匹配的 Pod
// replicas 副本的控制主要是通过relipcaset
template: // pod运行的参数
metadata:
labels:
app: nginx // pod 对应的标签
spec: // pod中容器对应的参数
containers:
- name: nginx // 容器名称
image: nginx:latest // 容器对应的镜像
imagePullPolicy: IfNotPresent // 镜像的拉取策略为节点中没有
ports:
- containerPort: 80 // nginx容器需要使用80端口通信，pod中的其他容器不能使用80端口
上面的配置文件，会创建一个名为nginx的deployment，这个deployment中需要启动两个pod，pod中是一个使用nginx镜像的容器。
为了避免需要拉取镜像，检查工作节点镜像环境。
root@node1 \~\]# crictl -r unix:///var/run/containerd/containerd.sock images nginx
[root@control ~]# kubectl apply -f nginx-deployment.yml
deployment.apps/nginx-deployment created
[root@control ~]# source .kube/k8s_bash_completion
[root@control ~]# kubectl describe deployments.apps nginx-deployment
Name: nginx-deployment
Namespace: default
CreationTimestamp: Mon, 23 Sep 2024 17:20:07 +0800
Labels: