Kubernetes
一、基础知识
1. 概念和术语
2. Kubernetes特性
3. 集群组件
4. 抽象对象
5. 镜像加速下载
二、安装部署kubeadm
1. 基础环境准备
2. 安装runtime容器(Docker)
3. 安装runtime容器(Contained)
4. Containerd进阶使用
5. 部署kubernets集群
6. 部署calico网络组件
7. 部署NFS文件存储
8. 部署ingress-nginx代理
9. 部署helm包管理工具
10. 部署traefik代理
11. 部署dashboard管理面板(官方)
12. 部署kubesphere管理面板(推荐)
12. 部署metrics监控组件
13. 部署Prometheus监控
14. 部署elk日志收集
15. 部署Harbor私有镜像仓库
16. 部署minIO对象存储
17. 部署jenkins持续集成工具
三、kubectl命令
1. 命令格式
2.node操作常用命令
3. pod常用命令
4.控制器常用命令
5.service常用命令
6.存储常用命令
7.日常命令总结
8. kubectl常用命令
四、资源对象
1. K8S中的资源对象
2. yuml文件
3. Kuberbetes YAML 字段大全
4. 管理Namespace资源
5. 标签与标签选择器
6. Pod资源对象
7. Pod生命周期与探针
8. 资源需求与限制
9. Pod服务质量(优先级)
五、资源控制器
1. Pod控制器
2. ReplicaSet控制器
3. Deployment控制器
4. DaemonSet控制器
5. Job控制器
6. CronJob控制器
7. StatefulSet控制器
8. PDB中断预算
六、Service和Ingress
1. Service资源介绍
2. 服务发现
3. Service(ClusterIP)
4. Service(NodePort)
5. Service(LoadBalancer)
6. Service(ExternalName)
7. 自定义Endpoints
8. HeadlessService
9. Ingress资源
10. nginx-Ingress案例
七、Traefik
1. 知识点梳理
2. 简介
3. 部署与配置
4. 路由(IngressRoute)
5. 中间件(Middleware)
6. 服务(TraefikService)
7. 插件
8. traefikhub
9. 配置发现(Consul)
10. 配置发现(Etcd)
八、存储
1. 配置集合ConfigMap
6. downwardAPI存储卷
3. 临时存储emptyDir
2. 敏感信息Secret
5. 持久存储卷
4. 节点存储hostPath
7. 本地持久化存储localpv
九、rook
1. rook简介
2. ceph
3. rook部署
4. rbd块存储服务
5. cephfs共享文件存储
6. RGW对象存储服务
7. 维护rook存储
十、网络
1. 网络概述
2. 网络类型
3. flannel网络插件
4. 网络策略
5. 网络与策略实例
十一、安全
1. 安全上下文
2. 访问控制
3. 认证
4. 鉴权
5. 准入控制
6. 示例
十二、pod调度
1. 调度器概述
2. label标签调度
3. node亲和调度
4. pod亲和调度
5. 污点和容忍度
6. 固定节点调度
十三、系统扩展
1. 自定义资源类型(CRD)
2. 自定义控制器
十四、资源指标与HPA
1. 资源监控及资源指标
2. 监控组件安装
3. 资源指标及其应用
4. 自动弹性缩放
十五、helm
1. helm基础
2. helm安装
3. helm常用命令
4. HelmCharts
5. 自定义Charts
6. helm导出yaml文件
十六、k8s高可用部署
1. kubeadm高可用部署
2. 离线二进制部署k8s
3. 其他高可用部署方式
十七、日常维护
1. 修改节点pod个数上限
2. 集群证书过期更换
3. 更改证书有效期
4. k8s版本升级
5. 添加work节点
6. master节点启用pod调度
7. 集群以外节点控制k8s集群
8. 删除本地集群
9. 日常错误排查
10. 节点维护状态
11. kustomize多环境管理
12. ETCD节点故障修复
13. 集群hosts记录
14. 利用Velero对K8S集群备份还原与迁移
15. 解决K8s Namespace无法正常删除的问题
16. 删除含指定名称的所有资源
十八、k8s考题
1. 准备工作
2. 故障排除
3. 工作负载和调度
4. 服务和网络
5. 存储
6. 集群架构、安装和配置
本文档使用 MrDoc 发布
-
+
home page
4. 抽象对象
>Kubernetes对集群中的资源进行了不同级别的抽象,每个资源都是一个REST对象,通过API进行操作,通过json或yaml格式的模板文件进行定义。 # 一、抽象资源对象 ## 容器组/Pod 在Kubernetes中,并不直接操作容器,最小的管理单位是容器组(Pod)。容器组由一个或多个容器组成,Kubernetes围绕容器组进行创建、调度、停止等生命周期管理。 同一个容器组中,各个容器共享命名空间(包括网络、IPC、文件系统等容器支持的命名空间)、cgroups限制和存储卷。这意味着同一个容器组中,各个应用可以很方便地相互进行访问,比如通过localhost地址进行网络访问,通过信号量和共享内存进行进程间通信等,类似经典场景中运行在同一个操作系统中的一组进程。可以简单地将一个Pod当作是一个抽象的“虚拟机”,里面运行若干个不同的进程(每个进程实际上就是一个容器)。 实现上,是先创建一个`gcr.io/google_containers/pause`容器,创建相关命名空间,然后创建Pod中的其他应用容器,并共享pause容器的命名空间。 组成容器组的若干容器往往是存在共同的应用目的,彼此关联十分紧密,例如一个Web应用与对应的日志采集应用、状态监控应用。如果单纯把这些相关的应用放一个容器里面,又会造成过度耦合,管理、升级都不方便。 容器组既保持了容器轻量解耦的特性,又提供了调度操作的便利性,在实践中提供了比单个容器更为灵活和更有意义的抽象。 ## 服务/Service 服务(Service)的提出,主要是要解决Pod地址可变的问题。由于Pod随时可能发生故障,并可能在其他节点上被重启,它的地址是不能保持固定的。因此,用一个服务来代表提供某一类功能(可以通过标签来筛选)的一些Pod,并分配不随Pod位置变化而改变的虚拟访问地址(Cluster IP)。 典型情况是,比如网站的后端服务,可能有多个Pod都运行了后端处理程序,它们可以组成一个服务。前端只需通过服务的唯一虚拟地址来访问即可,而无须关心具体是访问到了哪个Pod。可见,服务跟负载均衡器实现的功能很相似。 根据访问方式的不同,服务可以分为如下几种类型: - ClusterIP:提供一个集群内部的地址,该地址只能在集群内解析和访问。ClusterIP是默认的服务类型; - NodePort:在每个集群节点上映射服务到一个静态的本地端口(默认范围为30000~32767)。从集群外部可以直接访问,并自动路由到内部自动创建的ClusterIP; - LoadBalancer:使用外部的路由服务,自动路由访问到自动创建的NodePort和ClusterIP; - ExternalName:将服务映射到externalName域指定的地址,需要1.7以上版本kube-dns的支持。 组成一个服务的Pod可能是属于不同复制控制器的,但服务自身是不知道复制控制器的存在的。 ## 存储卷/Volume 即容器挂载的数据卷,跟Pod有一致的生命周期,Pod生存过程(包括重启)中,数据卷跟着存在;Pod退出,则数据卷跟着退出。 几个比较常见的数据卷类型包括:emptyDir、hostPath、gcePersistentDisk、awsElastic-BlockStore、nfs、gitRepo、secret。 - **emptyDir** 当Pod创建的时候,在节点上创建一个空的挂载目录,挂载到容器内。当Pod从节点离开(例如删除掉)的时候,自动删除挂载目录内数据。节点上的挂载位置可以为物理硬盘或内存。这一类的挂载适用于非持久化的存储,例如与Pod任务相关的临时数据等。除此之外,其他存储格式大都是持久化的; - **hostPath** 将节点上某已经存在的目录挂载到Pod中,Pod退出后,节点上的数据将保留; - **gcePersistentDisk** 使用GCE的Persistent Disk服务,Pod退出后,会保留数据; - **awsElasticBlockStore** 使用AWS的EBS Volume服务,数据也会持久化保留; - **nfs** 使用NFS协议的网络存储,也是持久化数据存储; - **gitRepo** 挂载一个空目录到Pod,然后clone指定的git仓库代码到里面,适用于直接从仓库中给定版本的代码来部署应用; - **secret** 用来传递敏感信息(如密码等),基于内存的tmpfs,挂载临时秘密文件。 持久化的存储以插件的形式提供为PersistentVolume资源,用户通过请求某个类型的PersistentVolumeClaim资源,来从匹配的持久化存储卷上获取绑定的存储。 # 二、控制器抽象对象 控制器抽象对象是基于对所操控对象的进一步抽象,附加了各种资源的管理功能,目前主要包括副本集、部署、状态集、Daemon集、任务等。 ## 副本集/ReplicaSet 在Kubernetes看来,Pod资源是可能随时发生故障的,并不需要保证Pod的运行,而是在发生失败后重新生成。Kubernetes通过复制控制器来实现这一功能。 用户申请容器组后,复制控制器将负责调度容器组到某个节点上,并保证它的给定份数(replica)正常运行。当实际运行Pod份数超过数目,则终止某些Pod;当不足,则创建新的Pod。一般建议,即使Pod份数是1,也要使用复制控制器来创建,而不是直接创建Pod。 可以将副本集类比为进程的监管者(supervisor)的角色,只不过它不光能保持Pod的持续运行,还能保持集群中给定类型Pod同时运行的个数为指定值。Pod是临时性的,可以随时由副本集创建或者销毁,这意味着要通过Pod自身的地址访问应用是不能保证一致性的。Kubernetes通过服务的概念来解决这个问题。 ## 部署/Deployment 从1.2.0版本开始,Kubernetes将正式引入部署机制来支持更灵活的Pod管理,从而用户无须直接跟复制控制器打交道了。部署代表用户对集群中应用的一次更新操作,在副本集的基础上还支持更新操作。每次滚动升级(rolling-update),会自动将副本集中旧版本的Pod逐渐替换为新的版本。 另外,副本集也可以支持成为“横向Pod扩展器”的操作对象。 ## 状态集/StatefulSet 通常情况下,使用容器的应用都是不带状态的,意味着部署同一个应用的多个Pod彼此可以替换,而且生命周期可以是很短暂的。任何一个Pod退出后,Kubernetes在集群中可以自动创建一个并按照调度策略调度到节点上。无状态的应用时候,关心的主要是副本的个数,而不关心名称、位置等。 与此对应,某些应用需要关心Pod的状态(包括各种数据库和配置服务等),挂载独立的存储。一旦当某个Pod故障退出后,Kubernetes会创建同一命名的Pod,并挂载原来的存储,以便Pod中应用继续执行,实现了该应用的高可用性。 状态集正是针对这种需求而设计的,提供比副本集和部署更稳定可靠的运行支持。 ## 守护集/DaemonSet Daemon集适合于长期运行在后台的伺服类型应用,例如对节点的日志采集或状态监控等后台支持服务。 Daemon集的应用会确保在指定类型的每个节点上都运行一个该应用的Pod。可能是集群中所有节点,也可能是指定标签的一类节点。 ## 任务/Job 不同于长期运行的应用,任务(Job)代表批处理类型的应用。任务中应用完成某一类的处理即可退出,有头有尾。例如,计算Pi到多少位,可以指定若干个Pod成功完成计算,即算任务成功执行。 ## 横向Pod扩展器/HPA 横向Pod扩展器(Horizontal Pod Autoscaler, HPA)解决应用波动的情况。类似云里面的自动扩展组,扩展器根据Pod的使用率(典型如CPU、内存等)自动调整一个部署里面Pod的个数,保障服务在不同压力情况下保证平滑的输出效果。 控制管理器会定期检查性能指标,在满足条件时候触发横向伸缩。Kubernetes 1.6版本开始支持基于多个指标的伸缩。 # 三、其他抽象对象 ## 标签/Label 标签(Label)是一组键值对,用来标记所绑定对象(典型的就是Pod)的识别属性,进而可以分类。比如name=apache|nginx、type=web|db、release=alpha|beta|stable、tier=frontend|backend等。 另外,Label键支持通过/来添加前缀,可以用来标注资源的组织名称等。一般的,前缀不能超过253个字符,键名不能超过63个字符。 标签所定义的属性是不唯一的,这意味着不同资源可能带有相同的标签键值对。这些属性可以将业务的相关信息绑定到对象上,用来对资源对象进行分类和选择过滤。 ## 注解/Annotation 注解(Annotation)跟标签很相似,也是键值对,但并非用来标识对象,同时可以存储更多更复杂的信息。 不同的是,注解并不是为了分类资源对象,而是为了给对象增加更丰富的描述信息。这些信息是任意的,数据量可以很大,可以包括各种结构化、非结构化的数据。 常见的注解包括时间戳、发行信息、开发者信息等,一般是为了方便用户查找相关线索。 ## 选择器/Selector 基于资源对象上绑定的标签信息,选择器(Selector)可以通过指定标签键值对来过滤出一组特定的资源对象。 选择器支持的语法包括基于等式(Equality-based)的,和基于集合(Set-based)的。 基于等式的选择,即通过指定某个标签是否等于某个值,例如env=production或者tier!=frontend等。多个等式可以通过AND逻辑组合在一起。 基于集合的选择,即通过指定某个标签的值是否在某个集合内,例如env in (staging, production)。 ## 秘密数据/Secret 秘密数据(Secret)资源用来保存一些敏感的数据,这些数据(例如密码)往往不希望别的用户看到,但是在启动某个资源(例如Pod)的时候需要提供。通过把敏感数据放到Secret里面,用户只需要提供Secret的别名即可使用。 在对应容器(secret-test-pod.test-container)内,通过环境变量$SECRET_USERNAME和$SECRET_PASSWORD即可获取到原始的用户名和密码信息。 此外,还可以采用数据卷的方式把秘密数据的值以文件形式放到容器内。通常,秘密数据不要超过1 MB。 在整个过程中,只有秘密数据的所有人和最终运行的容器(准确的说,需要是同一个服务账号下面的)能获取原始敏感数据,只接触到Pod定义模板的人是无法获取到的。 ## UID和名字 Kubernetes用UID和名字(Name)来标识对象。其中,UID是全局唯一的,并且不能复用;而名字则仅仅要求对某种类型的资源(在同一个命名空间内)内是唯一的,并且当某个资源移除后,其名字可以被新的资源复用。 这意味着,可以创建一个Pod对象,命名为test,同样可以创建一个复制控制器,命名也为test。一般的,名字字符串的长度不要超过253个字符。 ## 命名空间/NameSpace 命名空间(Namespace)用来隔离不同用户的资源,类似租户或项目的概念。默认情况下,相同命名空间中的对象将具有相同的访问控制策略。 同一个命名空间内,资源不允许重名,但不同命名空间之间,允许存在重名。用户在创建资源的时候可以通过`–namespace=<some_namespace>`来指定所属的命名空间。 Kubernetes集群启动后,会保留两个特殊的命名空间: - default:资源未指定命名空间情况下,默认属于该空间; - kube-system:由Kubernetes系统自身创建的资源。 另外,大部分资源都属于某个命名空间,但部分特殊资源,如节点、持久存储等不属于任何命名空间。 ## 污点和容忍 污点(Taint)和容忍(Toleration)用于辅助管理Pod到工作节点的调度过程。具有某个污点的工作节点,在不容忍的Pod看来,要尽量避免调度到它上面去。 通常情况下,可以为一个工作节点注明若干污点,只有对这些污点容忍的Pod,才可以被调度到这些具有污点的节点上。
Nathan
June 3, 2024, 1:53 p.m.
转发文档
Collection documents
Last
Next
手机扫码
Copy link
手机扫一扫转发分享
Copy link
Markdown文件
PDF文件
Docx文件
share
link
type
password
Update password