Kubernetes知识点总结（持续更细）
2022-03-16 17:21:26 0 举报AI智能生成
Kubernetes知识点总结（持续更细）
作者其他创作
大纲/内容
云原生
Cloud native
Cloud native
定义
介绍说明
发展历史
公有云类型说明
资源管理器对比
K8S 其优势
K8S 组件说明
Borg 组件说明
K8S 结构说明
网络结构
组件结构
K8S 中的一些关键字解释
K8s 的主要特性？
自我修复
弹性伸缩
自动部署和回滚
服务发现和负载均衡
配置管理，加密配置
存储编排
K8S 解决了什么问题？
K8S 架构
整体概览
Master节点
Etcd
存储配置中心
可以在master 节点，也可以单独部署
API Server
K8S 集群的接口和通讯总线
K8S 的大脑
Listener 机制，可以发布事件
唯一可以操作 Etcd 的组件
Scheduler
K8S 集群中负责调度决策的组件
在哪个Worker 发布应用
Controller Manager
保证集群中 Pod 状态最终一致
Worker 节点
Kubelet
Worker 节点资源的管理者，负责与 API Server 通信
Pod
K8s平台的容器抽象，基本调度单位
Container Runtime
Worker 节点容器资源的管理者。
屏蔽容器的底层实现
Kube-Proxy
K8S 中服务（Service）网络的组件
屏蔽易变得 Pod IP
K8S 关键组件梳理
Master 节点与 Worker 节点通信流程
1.Kubectl 发布命令给 API server，API Server 将请求存储到 Etcd中。
2. Scheduler 通过 API Server 监听到有应用发布请求，选择合适的Worker 节点，告知API Server
3.API Server 通知 被选中的 Worker 节点上的 Kubelet发布应用，通过 Container Runtime 启动容器。发布状态实时告知 API Server
4. API Server通知所有Worker 节点上的 Kube-Proxy ，有新的发布，获取 PodIP，ClusterIP，端口等相关数据，
更新到本地 iptables，让本地的 Pod是可以通过 iptables 转发的方式，访问到新发布的 Pods。
更新到本地 iptables，让本地的 Pod是可以通过 iptables 转发的方式，访问到新发布的 Pods。
5. Controller Manager 通过 API Server 时刻监控应用健康状况，保证实际状态和预期状态一致。
总体架构
外网流量如果要访问 K8S 集群内部的服务，一般要走负载均衡器（LB），然后会通过 Kube-Proxy 转发到服务 Pods 上
除了上述组件，K8S 外围一般还有 存储，监控，日志分析，等配套服务支持。
K8S 网络模型
外部接入网络
解决了 K8s 如何将内部的Service 网路暴露出去。
NodePort
使用 Kube-proxy 在 Worker 节点上暴露一个监听端口将K8s内部的 Service 暴露出去的方式，叫做 NodePort，即：端口暴露在节点上。
使用 NodePort 暴露服务的简化模型
通过把 kind：Service 的type 设置为 type：NodePort 即可实现
那么问题来了？
如果一个 Service 的Pod 实例分布在多个节点，那么对外暴露Service 的时候如何做负载均衡呢？
使用 Loader Blanceer
对通过 把 kind：Service 的type 设置为 type：LoadBalancer 即可实现。
Ingress
有了 NodePort 和 LoadBalancer，将 K8s Service 暴露到外网的需求已经实现了，为啥还要引入 Ingress 呢？
省钱啊
因为每暴露出一个服务就需要一个 LB，而 LB 是要钱的，其实我们只要一个 LB + 一个网关就可以了。
引入 Ingress 的简化模型
Service 网络
服务注册与发现和负载均衡
Eureka
使用 Ribbon 做客户端负载均衡
Nacos
Consul
K8s Service Registry+DNS
Service Registry 通过 Etcd 实现
客户端负载均衡
ClusterIP
一个服务一个 ClusterIP，这个IP后面跟的不是一个服务实例，而是一个服务实例集群，所以叫CLusterIP
Kube-DNS
消费者 Pod 不直接调用 ClusterIP，因为 ClusterIP 也会变，而是通过 服务名 ，
而服务名和ClusterIP的映射就是通过 Kube-DNS 解析的。
而服务名和ClusterIP的映射就是通过 Kube-DNS 解析的。
Kube_proxy
只负责服务发现和修改iptables规则
K8s服务发现流程
1. Pod 实例发布时，（通过 kind：Delooyment），kubelet 会负责启动 Pod 实例，
启动完成后，kubelet 把 Pod IP 列表汇报给 Master 节点
启动完成后，kubelet 把 Pod IP 列表汇报给 Master 节点
2. Service 发布时，（通过kind：Service），K8s 会为 Service 分配 ClusterIP
3. 进行服务阶段时，Kube-Proxy 会监听Master 拿到ClusterIP 和 PodIP 列表的映射关系，
修改 iptables 转发规则，指示 iptables 在接收到 ClusterIP请求时，进行负载均衡并转发到对应的 Pod 上。
修改 iptables 转发规则，指示 iptables 在接收到 ClusterIP请求时，进行负载均衡并转发到对应的 Pod 上。
4. 进行服务调用时，一般通过 serviceName 先去 Kube-DNS 解析到 ClusterIP，
这个ClusetrIP 会被本地的 iptables 截获，通过负载均衡，转发到目标 Pod 上。
这个ClusetrIP 会被本地的 iptables 截获，通过负载均衡，转发到目标 Pod 上。
K8s 服务发现机制与 Eureka+Ribbon 机制的区别：
一，虽然都是 客户端负载均衡，但是 Ribbon 对客户端有侵入性。
而 K8s 的Kube_proxy 是独立的，每个 Worker 节点都有一个。
而 K8s 的Kube_proxy 是独立的，每个 Worker 节点都有一个。
二，Ribbon 代理转发是穿透的，而 K8s 的代理转发通过 iptables，
三，Ribbon 是 serviceName -> service 实例IP 的映射；
K8s 有两层映射：Kube_DNS 实现的 ServiceName -> ClusterIP
Kuber-Proxy 实现的 ClusterIP -> PodIP 的映射。
K8s 有两层映射：Kube_DNS 实现的 ServiceName -> ClusterIP
Kuber-Proxy 实现的 ClusterIP -> PodIP 的映射。
对比 K8s 服务发现机制和目前微服务主流的服务发现机制？
K8s 的服务发现机制明显抽象更好，
它通过 ClusterIP 统一屏蔽服务发现和负载均衡，一个服务一个ClusterIP。
并且对应用无侵入性。
它通过 ClusterIP 统一屏蔽服务发现和负载均衡，一个服务一个ClusterIP。
并且对应用无侵入性。
Pod 网络
有了Pod网络， K8s 集群内的所有 Pods 在逻辑上都可以看做在一个网络平面内，可以正常的IP寻址和互相通信。
同节点 的Pod 通信
虚拟网络
不同节点的 Pod 通信
路由方案
覆盖网络方案
Node 节点网络
这个一般由底层(公有云或数据中心)网络基础设施支持。可以理解为物理主机
基础概念
Pod 概念
自主式 Pod
Pod 就是一个虚拟主机
管理器管理的 Pod
RS、RC
副本控制器,通过标签选择器,管理 Pod 副本数
deployment
管理 Pod 的滚动升级,部署
在使用 Deployment 时,实际的 Pod 是由 ReplicaSet 创建和管理的
为什么要引入 Deployment 这种资源?
使用 Deployment 可以更容易的更新应用程序,因为可以直接定义整个 Deployment 资源所要到达的状态,
并让 K8S 处理中间状态.
并让 K8S 处理中间状态.
创建一个 Deployment 资源
yaml 模板文件
Deployment 也是由标签选择器,期望副本数,和 Pod 模板组成的,其中 Pod 是通过 内部自动创建的一个 ReplicaSet
管理的.
管理的.
创建完 Deployment 资源后, 会发现多了一个 ReplicaSet 和 三个 Pod,其中 Pod 的名称和 RS 的名称都是由 Deployment 的名称加上一个随机字符创组成的
随机字符串的值是什么含义?
其实是 Deployment 模板的hash值,这样同一个版本的 Deployment 始终对给定版版本的 Pod 创建相同的 ReplicaSet
升级 Deployment
两种策略
RollingUpdate: 滚动升级,新旧版本会同时存在
Recreate: 先删除旧版本,再创建新版本,会出现Pod 短暂不可用状态
升级命令: 手动修改 Deployment 中的标签值,并且 apply
滚动升级过程: 一个新的 ReplicaSet 会被创建然后慢慢扩容,同时之前版本的 ReplicaSet 会慢慢缩容至0.
HPA
StatefullSet
部署有状态的多副本应用
稳定的网络标识
Pod
牛
宠物
有规律的 Pod 名称(主机名)
一旦 Pod 挂掉,会有一个完全一样的 Pod 替换,包括主机名,网络和存储
扩容
索引值顺序增加
myapp-0
myapp-1
myapp-2
缩容
先删除最高索引值的示例
当删除了特定 PVC 的Pod 时,PVC 并不会被删除,需要手动删除
为每个 Pod 提供专属存储
添加 PVC
at-most-one
Statefulset 会保证 有相同标识和存储的 Pod 只会运行一个
DaemonSet
Job，Cronjob
服务发现
Pod 协同
网络通讯模式
网络通讯模式说明
组件通讯模式说明
Kubernetes 安装
系统初始化
Kubeadm 部署安装
常见问题分析
资源清单
K8S 中资源的概念
什么是资源
名称空间级别的资源
集群级别的资源
资源清单
yam 语法格式
通过资源清单编写 Pod
Pod 的生命周期
initC
Pod phase
容器探针
livenessProbe
readinessProbe
Pod hook
重启策略
Pod 控制器
Pod 控制器说明
什么是控制器
控制器类型说明
ReplicationController 和 ReplicaSet
Deployment
DaemonSet
Job
CronJob
StatefulSet
部署有状态的多副本应用
部署有状态集群应用
为每个Pod 提供独立的存储
ReplicaSet 通过 Pod 模板 创建多个 Pod副本,这些 Pod 副本除了 名字和 ip 不同,其它都是一样的,
因此 如果 Pod 声明了 一个 PVC ,那么多个Pod 共享同一个 PV
因此 如果 Pod 声明了 一个 PVC ,那么多个Pod 共享同一个 PV
保证 pod 副本有固定的名称和主机名
按预期顺序启停Pod 副本
同 DNS SRV 记录查询伙伴节点
Horizontal Pod Autoscaling
服务发现
Service 原理
Service 含义
Service 常见分类
ClusterIP
NodePort
ExternalName
Service 实现方式
userspace
iptables
ipvs
Ingress
Nginx
HTTP 代理访问
HTTPS 代理访问
使用 cookie 实现会话关联
BasicAuth
Nginx 进行重写
存储
configMap
定义概念
创建 configMap
使用目录创建
使用文件创建
使用字面值创建
Pod 中使用 configMap
ConfigMap 来替代环境变量
ConfigMap 设置命令行参数
通过数据卷插件使用ConfigMap
configMap 热更新
实现演示
更新触发说明
Secret
定义概念
概念说明
分类
Service Account
Opaque Secret
特殊说明
创建
使用
Secret 挂载到 Volume
Secret 导出到环境变量中
kubernetes.io/dockerconfigjson
volume(Pod 卷)
定义概念
卷?
Pod 可以认为是一个虚拟主机,里面有许多容器,每个容器都有自己独立的文件系统
容器如何访问外部磁盘,如何在容器之间共享存储空间?
k8s 的 卷是 Pod 的一个组成部分
Pod 卷的几种类型
emptyDir
说明
用于存储临时数据的简单空目录
emptyDir 最后也是在 Pod 所在的 Worker Node 上的磁盘上创建的
随着 Pod 删除而删除
用途假设
可用于在一个 Pod 中的多个容器间共享数据
实验演示
gitRepo
说明
通过检出 Git 仓库的内容来初始化的卷
只有在 Pod 启动时,才会拉取git仓库的内容.
随着 Pod 删除而删除
hostPath
说明
用于将 Worker Node 上的文件系统挂载到 Pod 中
需要注意的是,在 k8s 的设计哲学中,大多数Pod 都应该忽略承载它们的 工作节点, 但有一些系统级别的 Pod 例外
持久性存储
用途说明
系统级别的 Pod, 每个 Worker Node 上都需要有的一类 Pod
实验演示
NAS
说明
如果一个 Pod 需要存储数据,并且无论将来自己被调度到哪个节点,都能访问原来的存储数据,那么上面的集中类型都不满足我们的需求.
必须将其存储到某种网络类型的存储中.(NAS)
必须将其存储到某种网络类型的存储中.(NAS)
可以使用各家云厂商提供的 高效能型 磁盘
阿里云 NAS
挂载到 Pod 中的 NFS 共享卷
PV(持久卷)
概念解释
PV
持久卷 被 集群管理员创建,并被 Pod 通过持久卷声明来使用
创建持久卷
在创建时可以声明该持久卷的一些参数配置:
是由单节点消费还是多节点
绑定到该 PV上的 PVC 被删除后, 做哪些策略?是保留数据还是删除等
持久卷不属于任何命空间,它和节点一样是属于集群层面的资源
PVC
使用持久卷
通过 持久卷声明来使用持久卷
创建持久卷声明
当创建好持久卷声明后,k8s 会自动找到合适的持久卷,并把它绑定到持久卷声明
在 Pod 中使用持久卷声明
示例
直接使用磁盘 和通过 PV 和PVC间接使用磁盘?
直接使用磁盘
PV 和 PVC使用磁盘
这种间接方式从基础设施获取存储, K8s 的设计理念就是面向资源调度,
开发人员只需要声明自己需要的资源,底层存储不不需要关心
开发人员只需要声明自己需要的资源,底层存储不不需要关心
PV(持久卷)
后端类型
PV 访问模式说明
回收策略
存在两种持久卷回收策略:
Retain
Delete
Recycle
状态
实例演示
PVC(持久卷声明)
PVC 实践演示
调度器
调度器概念
概念
调度过程
自定义调度器
调度亲和性
nodeAffinity
preferredDuringSchedulingIgnoredDuringExecution
requiredDuringSchedulingIgnoredDuringExecution
podAntiAffinity
preferredDuringSchedulingIgnoredDuringExecution
requiredDuringSchedulingIgnoredDuringExecution
亲和性运算符
污点
污点概念
Taint
组成
污点的设置、查看和去除
Tolerations
tolerations 设置演示
固定节点调度
PodName 指定调度
标签选择器调度
集群安全机制
机制说明
认证
HTTP Token
HTTP Base
HTTPS
鉴权
AlwaysDeny
AlwaysAllow
ABAC
Webbook
RBAC
RBAC
Role and ClusterRole
RoleBinding and ClusterRoleBinding
Resources
to Subjects
创建一个系统用户管理 k8s dev 名称空间：重要实验
准入控制
HELM
HELM 概念
HELM 概念说明
组将构成
HELM 部署
HELM 自定义
HELM 部署实例
HELM 部署 dashboard
metrics-server
HPA 演示
资源限制
Pod
名称空间
Prometheus
EFK
运维
Kubeadm 源码修改
Kubernetes 高可用构建
0 条评论
下一页
