K8s概念相关
k8s基础概念
1. k8s: 连接众多计算机成为集群资源池
1
2
3
4
5
6
7
8
9
10
11
12
13
14
涉及名词概念
etcd: 读写信息的存储, 所有的信息都存储在这，保存了整个集群的状态；持久化
apiserver: 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
controller manager: 负责维护集群的状态，维持副本期望数目，比如故障检测、自动扩展、滚动更新等；
scheduler: 负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
kubelet: 负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
Container runtime: 负责镜像管理以及Pod和容器的真正运行（CRI）；
kube-proxy: 负责为Service提供cluster内部的服务发现和负载均衡; 是一个分布式代理服务器，在K8s的每个节点上都有一个
2. 学习k8s各部分需要掌握的东西
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Pod控制器: 掌握各种控制器的特点以及使用定义方式;
服务发现: 掌握 SVC 原理及其构建方式;
存储: 掌握多种存储类型的特点, 并且能够在不同环境中选择合适的存储方案(有自己的见解)
调度器: 掌握调度器的原理, 能根据要求把Pod定义到想要的节点运行
安全: 集群的认证、鉴权、访问控制 原理及其流程
HELM: Linux yum 掌握 HELM 原理 HELM 面板自定义、部署一些常用软件
运维: 修改 kubeadm 可用证书期限修改为10年甚至更高
服务分类: 有状态服务: DBMS
无状态服务: LVS APACHE
3. deployment启动pod
用户通过 kubectl 创建 Deployment。
Deployment 创建 ReplicaSet。
ReplicaSet 创建 Pod
详细过程
1. kubectl 向 apiserver 发送部署请求（例如使用 kubectl create -f deployment.yml）
2. apiserver 将 Deployment 持久化到 etcd；etcd 与 apiserver 进行一次http通信。
3. controller manager 通过 watch api 监听 apiserver ，deployment controller看到了一个新创建的 deplayment对象 更后，将其从队列中拉出，根据deployment 的描述 创建一个ReplicaSet，并将 ReplicaSet 对象返回apiserver并持久化回etcd。以此类推，当replicaset控制器看到新创建的replicaset对象，将其从队列中拉出，根据描述创建pod对象。
4. 接着 scheduler 调度器看到未调度的pod对象，根据调度规则选择一个可调度的节点，加载到pod描述中nodeName字段，并将pod对象返回 apiserver 并写入 etcd。
5. kubelet 在看到有 pod对象 中 nodeName 字段属于本节点，将其从队列中拉出，通过容器运行时创建 pod 中描述的容器。
4. ReplicaSet控制pod
1
确保容器应用的副本数始终保持在用户定义的副本数
5. k8s中各类控制器的关系
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
控制器的选择取决于应用程序的需求和管理模式。
只有需要管理 Pod 副本的控制器（如 Deployment 和 StatefulSet）会依赖 ReplicaSet。其他控制器如 DaemonSet 和 Job 则独立管理 Pods。
各类控制器与ReplicaSet控制器的关系:
==========================================================================
1. Deployment
依赖关系: Deployment 控制器直接使用 ReplicaSet 来管理 Pods。每次更新或扩展时，Deployment 会创建新的 ReplicaSet。
2. StatefulSet
依赖关系: StatefulSet 使用 ReplicaSet 来管理有状态的 Pods，但提供了有序性和持久性的保证。
3. DaemonSet
依赖关系: DaemonSet 控制器不使用 ReplicaSet。它确保每个节点（或选定的节点）运行一个 Pod 实例，适用于日志收集、监控等场景。
4. Job 和 CronJob
依赖关系: Job 和 CronJob 控制器也不依赖于 ReplicaSet。它们用于批处理任务，确保 Pods 完成特定工作。
5. ReplicationController
依赖关系: ReplicationController 是 ReplicaSet 的前身，管理无状态 Pods，但现在更推荐使用 ReplicaSet。
6. pause容器作用
pause容器主要为每个业务容器提供以下功能：
① PID命名空间：Pod中的不同应用程序可以看到其他应用程序的进程ID。
② 网络命名空间：Pod中的多个容器能够访问同一个IP和端口范围。
③ IPC命名空间：Pod中的多个容器能够使用SystemV IPC或POSIX消息队列进行通信。
④ UTS命名空间：Pod中的多个容器共享一个主机名；Volumes（共享存储卷）：
⑤ Pod中的各个容器可以访问在Pod级别定义的Volumes。
pause容器 主要为每个业务容器提供以下功能： 在pod中担任Linux命名空间共享的基础
k8s-pv-持久化-持久访问模式
1. ReadOnlyMany – 卷可以被许多节点以只读方式挂载
1
2
3
4
5
6
7
如果一个 pod 挂载了一个 ReadOnlyMany 访问模式的卷，其他 pod 可以挂载它并且只执行读取操作。现在 GCP 不支持这种方法。
这意味着卷可以挂载在 Kubernetes 集群的一个或多个节点上，并且您只能执行读取操作。
您有一个 Pod 在节点上运行，并且您正在从卷中读取存储的文件。在同一卷上，您无法执行写入操作。
由于它是 ReadOnlyMany，如果您的 pod 被调度到另一个节点，那么卷和数据也将可用于执行读取操作。
2. ReadWriteMany – 卷可以被许多节点以读写方式挂载
1
2
3
4
5
6
7
如果一个 pod 挂载了一个 ReadWriteMany 访问方式的卷，其他 pod 也可以挂载它。
这意味着卷可以挂载在 kubernetes 集群的一个或多个节点上，您可以同时执行读写操作。
您在一个节点上运行了一个 pod，并且您正在从卷中读取和写入存储的文件。
由于它是 ReadWriteMany，如果您的 pod 调度到另一个节点，那么卷和数据也将在那里可用以执行读/写操作。
3. ReadWriteOnce – 卷可以由单个节点以读写方式挂载
1
2
3
4
5
6
7
如果 pod 以 ReadWriteOnce 访问模式挂载卷，则其他 pod 无法挂载它。在 GCE (Google Compute Engine) 中，唯一允许的模式是 ReadWriteOnce 和 ReadOnlyMany。因此，要么一个 pod 挂载 ReadWrite 卷，要么一个或多个 pod 挂载 ReadOnlyMany 卷。
这意味着卷可以挂载在onlykubernetes 集群的一个节点上，并且您只能执行读取操作。
您在节点上运行了一个 pod，并且您正在从卷中读取存储的文件。在同一卷上时，您无法执行写入。
因为它是 ReadWriteOnce 如果您的 pod 被安排到另一个节点，那么可能 mossible 卷将附加到该节点并且您无法访问那里的数据。
Pod指标WSS和RSS区别
1. WSS（Working Set Size）
- 定义：
- WSS 是指 Pod 当前正在使用的内存量，包括活跃的、最近被访问的和缓存的内存。它代表了应用程序实际需要的内存量。
- 特点：
- WSS 是动态变化的，随着应用程序的运行状态而变化。
- 它更能反映应用程序的实时内存需求，因此对资源调度和优化非常重要。
- WSS 不包括被操作系统回收或未被使用的内存。
2. RSS（Resident Set Size）
- 定义：
- RSS 是指进程占用的物理内存量，不包括被交换出去的部分。它是指进程在内存中实际驻留的部分，包括代码、数据和堆栈。
- 特点：
- RSS 是相对静态的，通常在进程运行期间变化较小。
- 它包括所有分配的内存，无论是否被使用。
- RSS 可以帮助识别内存泄漏，因为如果 RSS 不断增加而 WSS 稳定，可能意味着有不再使用的内存仍然被保留。
3. 总结
- WSS：反映应用程序当前的实际内存需求，动态变化，更关注活跃和近期使用的内存。
- RSS：表示进程在物理内存中占用的总量，包括所有分配的内存，适合监控内存使用的整体情况。
了解这两个指标的区别有助于更好地进行资源管理和优化。监控 WSS 和 RSS 可以帮助识别性能瓶颈、内存泄漏等问题，从而更有效地调度和配置 Kubernetes 集群中的资源。