网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
Pod的“控制器”通常包含一个名为“replicas”的属性。“replicas”属性则指定了特定Pod的副本的数量,当当前集群中该Pod的数量与该属性指定的值不一致时,k8s会采取一些策略去使得当前状态满足配置的要求。
1.2 控制器
1.2.1 适用无状态服务
1.2.1.1 ReplicationController(RC)
Replication Controller简称 RC,RC是Kubernetes系统中的核心概念之一,简单来说,RC可以保证在任意时间运行Pod的副本数量,能够保证Pod总是可用的。如果实际Pod数量比指定的多那就结束掉多余的,如果实际数量比指定的少就新启动一些Pod,当Pod失败、被删除或者挂掉后,RC都会去自动创建新的Pod来保证副本数量,所以即使只有一个Pod,我们也应该使用 RC来管理我们的Pod。可以说,通过Replication Controller,Kubernetes实现了Pod的高可用性。
1.2.1.2 ReplicaSet(RS)
RC(ReplicationController )主要的作用就是用来确保容器应用的副本数始终保持在用户定义的副本数 。即如果有容器异常退出,会自动创建新的Pod来替代;而如果异常多出来的容器也会自动回收(已经成为过去时),在v1.11版本废弃。
Kubernetes官方建议使用RS(ReplicaSet ) 替代RC (ReplicationController ) 进行部署,RS跟RC没有本质的不同,只是名字不一样,并且RS支持集合式的selector。
Label:
label(标签)是附加到Kubernetes对象(比如 Pods)上的键值对,用于区分对象(比如Pod、Service)。 label旨在用于指定对用户有意义且相关的对象的标识属性,但不直接对核心系统有语义含义。 label可以用于组织和选择对象的子集。label可以在创建时附加到对象,随后可以随时添加和修改。可以像namespace一样,使用label来获取某类对象,但label可以与selector一起配合使用,用表达式对条件加以限制,实现更精确、更灵活的资源查找。
Selector:
label与selector配合,可以实现对象的“关联”,“Pod控制器”与Pod是相关联的 —— “Pod控制器”依赖于Pod,可以给Pod设置label,然后给“控制器”设置对应的selector,这就实现了对象的关联。
RS的作用是帮助动态更新Pod副本数,因为每个Pod上都有唯一的标签,RS可以通过selector来选择对哪些标签的Pod生效配置。
1.2.1.3 Deployment
针对RS的更高层级的封装,提供了更丰富的部署相关功能。
Deployment 为 Pod 和 Replica Set 提供声明式更新。
你只需要在 Deployment 中描述你想要的目标状态是什么,Deployment controller 就会帮你将 Pod 和 Replica Set 的实际状态改变到你的目标状态。你可以定义一个全新的 Deployment,也可以创建一个新的替换旧的 Deployment。
- 自动创建 Replica Set / Pod
- 滚动升级/回滚
- 平滑扩容和缩容
- 暂停与恢复 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 主要特点
- 稳定的持久化存储:即Pod重新调度后还是能访问到相同的持久化数据,基于PVC来实现。
- 稳定的网络标志:稳定的网络标志,即Pod重新调度后其PodName和HostName不变,基于Headless Service(即没有Cluster IP的Service)来实现。
- 有序部署,有序扩展:有序部署,有序扩展,即Pod是有顺序的,在部署或者扩展的时候要依据定义的顺序依次依次进行(即从0到N-1,在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态),基于init containers来实现。
- 有序收缩,有序删除:有序收缩,有序删除(即从 N-1 到 0)。
1.2.2.2 组成
Headless Service:有状态服务的网络管理。
用于定义网络标志(DNS domain)
Domain Name Server:域名服务
将域名与ip绑定映射关系
服务名 => 访问路径(域名) => ip
volumeClaimTemplate:用于创建持久化卷的模板PersistentVolumes。
1.2.2.3 注意事项
- kubernetes v1.5版本以上才支持。
- 所有Pod的Volume必须使用PersistentVolume或者是管理员事先创建好。
- 为了保证数据安全,删除StatefulSet时不会删除Volume。
- 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
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上Go语言开发知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上Go语言开发知识点,真正体系化!**
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新