既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

RS的作用是帮助动态更新Pod副本数，因为每个Pod上都有唯一的标签，RS可以通过selector来选择对哪些标签的Pod生效配置。

1.2.1.3 Deployment

针对RS的更高层级的封装，提供了更丰富的部署相关功能。

Deployment 为 Pod 和 Replica Set 提供声明式更新。

你只需要在 Deployment 中描述你想要的目标状态是什么，Deployment controller 就会帮你将 Pod 和 Replica Set 的实际状态改变到你的目标状态。你可以定义一个全新的 Deployment，也可以创建一个新的替换旧的 Deployment。

1. 自动创建 Replica Set / Pod
2. 滚动升级/回滚
3. 平滑扩容和缩容
4. 暂停与恢复 Deployment：便于一次性更改多个配置后再升级。

1.2.2 适用有状态服务 StatefulSet

可以实现的功能：网络域名可以固定，对应的数据不会丢失，启动的顺序不变。

StatefulSet 中每个 Pod 的 DNS 格式为 statefulSetName-{0…N-1}.serviceName.namespace.svc.cluster.local

• serviceName 为 Headless Service 的名字
• 0…N-1 为 Pod 所在的序号，从 0 开始到 N-1
• statefulSetName 为 StatefulSet 的名字
• namespace 为服务所在的 namespace，Headless Servic 和 StatefulSet 必须在相同的 namespace
• .cluster.local 为 Cluster Domain

1.2.2.1 主要特点

1. 稳定的持久化存储：即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现。
2. 稳定的网络标志：稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现。
3. 有序部署，有序扩展：有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现。
4. 有序收缩，有序删除：有序收缩，有序删除（即从 N-1 到 0）。

1.2.2.2 组成

Headless Service：有状态服务的网络管理。
用于定义网络标志（DNS domain）

Domain Name Server：域名服务
将域名与ip绑定映射关系

服务名 => 访问路径（域名） => ip

---

volumeClaimTemplate：用于创建持久化卷的模板PersistentVolumes。

1.2.2.3 注意事项

1. kubernetes v1.5版本以上才支持。
2. 所有Pod的Volume必须使用PersistentVolume或者是管理员事先创建好。
3. 为了保证数据安全，删除StatefulSet时不会删除Volume。
4. StatefulSet需要一个Headless Service来定义DNS domain，需要在StatefulSet之前创建好。

1.3 守护进程 DaemonSet

是基于选择器（selector）将所有匹配到的Pod都部署成守护进程的程序。

DaemonSet保证在每个Node上都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括：

• 日志收集，比如 fluentd，logstash 等
• 系统监控，比如 Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond 等
• 系统程序，比如 kube-proxy, kube-dns, glusterd, ceph 等

1.4 任务/定时任务

Job：一次性任务（Pod），运行完成后Pod销毁，不再重新启动新容器。
CronJob：CronJob是在Job基础上加上了定时功能。

2 服务发现

2.1 Service

实现k8s集群内部网络调用，负载均衡（四层负载）。

“Service” 简写 “svc”。Pod 不能直接提供给外网访问，而是应该使用 service。Service 就是把 Pod 暴露出来提供服务，Service 才是真正的“服务”，它的中文名就叫“服务”。

可以说 Service 是一个应用服务的抽象，定义了 Pod 逻辑集合和访问这个 Pod 集合的策略。Service 代理 Pod 集合，对外表现为一个访问入口，访问该入口的请求将经过负载均衡，转发到后端 Pod 中的容器。

2.2 Ingress

将k8s内部服务暴露给外网访问的服务。里面有Ingree-nginx反向代理、负载均衡（七层负载）

Ingress 可以提供外网访问 Service 的能力。可以把某个请求地址映射、路由到特定的 service。

ingress 需要配合 ingress controller 一起使用才能发挥作用，ingress 只是相当于路由规则的集合而已，真正实现路由功能的，是 Ingress Controller，ingress controller 和其它 k8s 组件一样，也是在 Pod 中运行。

3 存储

3.1 Volume

数据卷，共享 Pod 中容器使用的数据。用来放持久化的数据，比如数据库数据。

3.2 CSI

Container Storage Interface 是由来自 Kubernetes、Mesos、Docker 等社区成员联合制定的一个行业标准接口规范，旨在将任意存储系统暴露给容器化应用程序。

CSI 规范定义了存储提供商实现 CSI 兼容的 Volume Plugin 的最小操作集和部署建议。CSI 规范的主要焦点是声明 Volume Plugin 必须实现的接口。

4 特殊类型配置

4.1 ConfigMap

用来放配置，与 Secret 是类似的，只是 ConfigMap 放的是明文的数据，Secret 是密文存放。

4.2 Secret

Secret 解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者 Pod Spec 中。Secret 可以以 Volume 或者环境变量的方式使用。

Secret 有三种类型：

• Service Account：用来访问 Kubernetes API，由 Kubernetes 自动创建，并且会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中；
• Opaque：base64 编码格式的 Secret，用来存储密码、密钥等；
• kubernetes.io/dockerconfigjson：用来存储私有 docker registry 的认证信息。

4.3 DownwardAPI

downwardAPI 这个模式和其他模式不一样的地方在于它不是为了存放容器的数据也不是用来进行容器和宿主机的数据交换的，而是让 pod 里的容器能够直接获取到这个 pod 对象本身的一些信息。

downwardAPI 提供了两种方式用于将 pod 的信息注入到容器内部：

• 环境变量：用于单个变量，可以将 pod 信息和容器信息直接注入容器内部
• volume 挂载：将 pod 信息生成为文件，直接挂载到容器内部中去

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

不再深入研究，那么很难做到真正的技术提升。**

需要这份系统化的资料的朋友，可以添加戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！