Kubernetes (K8s) 是一种开源的容器编排引擎，用于自动化应用程序容器的部署、扩展和操作。它由Google设计并捐赠给Cloud Native Computing Foundation（CNCF）进行维护。Kubernetes 提供了一个强大的平台，用于构建和管理容器化应用程序的解决方案。
-
K8s基础概念
-
Kubernetes集群架构
-
Master节点组件
-
API Server
-
Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。 你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。
-
Scheduler
-
kube-scheduler 是控制平面的组件， 负责监视新创建的、未指定运行节点（node）的 Pods， 并选择节点来让 Pod 在上面运行。
-
调度决策考虑的因素包括单个 Pod 及 Pods 集合的资源需求、软硬件及策略约束、 亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。
-
Controller Manager
-
kube-controller-manager 是控制平面的组件， 负责运行控制器进程。
-
从逻辑上讲， 每个控制器都是一个单独的进程， 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。
-
Etcd
-
一致且高可用的键值存储，用作 Kubernetes 所有集群数据的后台数据库。
-
-
Node节点组件
-
节点组件会在每个节点上运行，负责维护运行的 Pod 并提供 Kubernetes 运行环境。
-
Kubernetes 通过将容器放入在节点（Node）上运行的 Pod 中来执行你的工作负载。 节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。 每个节点包含运行 Pod 所需的服务； 这些节点由控制面负责管理。
-
通常集群中会有若干个节点；而在一个学习所用或者资源受限的环境中，你的集群中也可能只有一个节点。
-
Kubelet
-
kubelet 会在集群中每个节点（node）上运行。 它保证容器（containers）都运行在 Pod 中。
-
kubelet 接收一组通过各类机制提供给它的 PodSpec，确保这些 PodSpec 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。
-
Kube-Proxy
-
kube-proxy 是集群中每个节点（node）上所运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。
-
kube-proxy 维护节点上的一些网络规则， 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。
-
如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。 否则，kube-proxy 仅做流量转发。
-
容器运行时(Container Runtime)
-
这个基础组件使 Kubernetes 能够有效运行容器。 它负责管理 Kubernetes 环境中容器的执行和生命周期。
-
Kubernetes 支持许多容器运行环境，例如 containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。
-
-
-
Kubernetes核心概念
-
Pods
-
Pod的生命周期
-
Pod的调度
-
-
Services
-
Kubernetes 中 Service 是 将运行在一个或一组 Pod 上的网络应用程序公开为网络服务的方法。
-
Ingress
-
Ingress 提供从集群外部到集群内服务的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 资源所定义的规则来控制。
-
Ingress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP。
-
Ingress 可以提供负载均衡、SSL 终结和基于名称的虚拟托管。
-
Service的类型
-
ClusterIP(默认缺省类型)
-
默认类型，Service会分配一个ClusterIP（集群内部IP），用于集群内部的访问。这意味着Service只能在Kubernetes集群内部的其他Pod中使用这个ClusterIP访问被Service代理的Pod。
-
NodePort
-
在ClusterIP的基础上，Service会在每个Node（节点）上开放一个固定的端口（NodePort），允许外部流量通过这个端口访问Service。NodePort类型的Service会使用集群节点的IP地址和NodePort端口来代理请求到Service中的Pod。
-
LoadBalancer
-
在NodePort的基础上，Kubernetes云服务提供商（如AWS、GCP、Azure等）会创建一个外部负载均衡器，并将负载均衡器配置为代理到Service的NodePort上。这样可以通过负载均衡器的IP来访问Service，负载均衡器将流量分发到集群中的Pod。
-
ExternaLName
-
这种类型的Service不会创建任何负载均衡器或ClusterIP，它只通过DNS返回一个外部服务的CNAME。主要用于访问集群外部的服务，将服务映射到一个外部名字。
-
-
Service的发现机制
-
-
Deployments
-
滚动更新
-
回滚
-
扩展与缩容
-
-
-
Kubernetes网络模型
-
CNI网络插件
-
Flannel
-
是一个可以用于 Kubernetes 的 overlay 网络提供者。
-
Calico
-
Calico 是一个联网和网络策略供应商。 Calico 支持一套灵活的网络选项，因此你可以根据自己的情况选择最有效的选项，包括非覆盖和覆盖网络，带或不带 BGP。 Calico 使用相同的引擎为主机、Pod 和（如果使用 Istio 和 Envoy）应用程序在服务网格层执行网络策略。
-
Canal
-
Canal 结合 Flannel 和 Calico，提供联网和网络策略。
-
-
Service Mesh
-
Istio
-
Linkerd
-
-
-
-
K8s高级特性
-
存储管理
-
持久卷(PersistentVolumes)
-
持久卷（PersistentVolume，PV） 是集群中的一块存储，可以由管理员事先制备， 或者使用存储类（Storage Class）来动态制备。 持久卷是集群资源，就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样， 也是使用卷插件来实现的，只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。 此 API 对象中记述了存储的实现细节，无论其背后是 NFS、iSCSI 还是特定于云平台的存储系统。
-
PV的生命周期
-
PV的类型
-
csi
-
容器存储接口（CSI）
-
fc
-
Fibre Channel（FC）存储
-
hostPath
-
HostPath 卷 （仅供单节点测试使用；不适用于多节点集群；请尝试使用 local 卷作为替代）
-
iscsi
-
iSCSI（IP 上的 SCSI）存储
-
local
-
节点上挂载的本地存储设备
-
nfs
-
网络文件系统（NFS）存储
-
-
PV的访问模式
-
RWO(ReadWriteOnce)
-
卷可以被一个节点以读写方式挂载。 ReadWriteOnce 访问模式仍然可以在同一节点上运行的多个 Pod 访问该卷。 对于单个 Pod 的访问，请参考 ReadWriteOncePod 访问模式。
-
ROX(ReadOnlyMany)
-
卷可以被多个节点以只读方式挂载
-
RWX(ReadWriteMany)
-
卷可以被多个节点以读写方式挂载。
-
RWOP(ReadWriteOncePod)
-
卷可以被单个 Pod 以读写方式挂载。 如果你想确保整个集群中只有一个 Pod 可以读取或写入该 PVC， 请使用 ReadWriteOncePod 访问模式。
-
ReadWriteOncePod 访问模式仅适用于 CSI 卷和 Kubernetes v1.22+。 要使用此特性，你需要将以下 CSI 边车更新为下列或更高版本：
-
csi-provisioner:v3.0.0+
-
csi-attacher:v3.3.0+
-
csi-resizer:v1.3.0+
-
-
PV与PVC的动态绑定
-
尽管 PersistentVolumeClaim 允许用户消耗抽象的存储资源， 常见的情况是针对不同的问题用户需要的是具有不同属性（如，性能）的 PersistentVolume 卷。 集群管理员需要能够提供不同性质的 PersistentVolume， 并且这些 PV 卷之间的差别不仅限于卷大小和访问模式，同时又不能将卷是如何实现的这些细节暴露给用户。 为了满足这类需求，就有了存储类（StorageClass） 资源。
-
-
存储类(StorageClass)
-
StorageClass的创建与使用
-
StorageClass的提供者
-
-
动态卷供应
-
Amazon Elastic Block Store(EBS)
-
默认每节点最大卷数:39
-
对于 M5、C5、R5、T3 和 Z1D 类型实例的 Amazon EBS 磁盘，Kubernetes 仅允许 25 个卷关联到节点。 对于 ec2 上的其他实例类型 Amazon Elastic Compute Cloud (EC2)， Kubernetes 允许 39 个卷关联至节点。
-
Google Presisten Disk
-
默认每节点最大卷数:16
-
在 Google Compute Engine环境中， 根据节点类型最多可以将 127 个卷关联到节点。
-
Microsoft Azure Disk Storage
-
默认每节点最大卷数:16
-
在 Azure 环境中, 根据节点类型，最多 64 个磁盘可以关联至一个节点。
-
-
-
资源配额与限制
-
资源请求与限制
-
CPU资源限制
-
内存资源限制
-
-
配额管理
-
ResourceQuota
-
CPU与内存配额
-
Pod配额
-
-
LimitRange
-
CPU与内存限制
-
其他资源限制
-
-
-
-
安全与认证
-
RBAC（基于角色的访问控制）
-
角色(Role)与集群角色(ClusterRole)
-
角色绑定(RoleBinding)与集群角色绑定(ClusterRoleBinding)
-
-
身份认证
-
网络策略(Network Policies)
-
定义网络策略
-
应用网络策略
-
-
-
集群监控与日志
-
日志收集与查询
-
Fluentd
-
ELK Stack（Elasticsearch, Logstash, Kibana）
-
-
监控组件与工具
-
Prometheus
-
Prometheus架构
-
Prometheus监控配置
-
-
Grafana
-
Grafana与Prometheus集成
-
Grafana仪表板创建
-
-
-
-
集群备份与恢复
-
Velero
-
Velero组件
-
Velero备份与恢复操作
-
-
-
K8s的网络管理
-
网络模型与组件
-
CNI（容器网络接口）
-
网络插件 是实现容器网络接口（CNI）规范的软件组件。它们负责为 Pod 分配 IP 地址，并使这些 Pod 能在集群内部相互通信。
-
Calico、Flannel等网络插件
-
-
服务发现
-
DNS服务发现
-
Ingress
-
-
网络策略
- Network Policy实现网络隔离
-
-
-
云原生生态
-
容器技术
-
Docker
-
Docker的镜像与容器
-
Docker Compose与Docker Swarm
-
-
容器镜像仓库
-
Harbor
-
Harbor安装与配置
-
Harbor镜像管理
-
-
Docker Hub
-
Docker Hub账户管理
-
Docker Hub镜像管理
-
-
-
-
服务网格
-
Istio
-
Istio服务发现
-
Istio流量管理
-
-
服务网格的概念
- 服务网格的优势
-
-
持续集成/持续部署(CI/CD)
-
Jenkins
-
Jenkins安装与配置
-
Jenkins Pipeline构建
-
-
GitLab CI/CD
-
GitLab CI/CD配置
-
GitLab CI/CD执行流程
-
-
-
微服务治理
-
服务发现
-
CoreDNS 是一种灵活的，可扩展的 DNS 服务器，可以 安装为集群内的 Pod 提供 DNS 服务。
-
Consul
-
Eureka
-
-
服务治理
-
服务治理能力
-
限流与削峰
-
熔断与降级
-
-
Service Mesh(微服务架构设计模式)
-
Istio
-
Linkerd和Envoy
-
-
-
-
DevOps文化与实践
-
敏捷开发
-
Scrum
-
Kanban
-
-
自动化运维
-
Ansible
-
Chef/Puppet
-
-
-
KubeSphere - 企业级K8s平台
-
KubeSphere的功能特性
-
多租户管理
-
DevOps集成
-
-
KubeSphere的部署与配置
-
All-in-one安装
-
多节点安装
-
-
-
Knative - 自动化Serverless部署
-
Knative Serving
-
服务部署与路由
-
服务扩展与缩容
-
-
Knative Eventing
-
事件源（Event Sources）
-
事件触发器（Event Triggers）
-
-
-
