阅读量:0
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）
