This page looks best with JavaScript enabled

K8S 技术分享讲义

 ·  ☕ 9 min read  ·  👻 睡沙发の沙皮狗 · 👀... views

技术分享信息

  • 课题:K8S 学习分享交流会 – 基础知识及功能特性分析
  • 讲解人员:i@leeif.me
  • 参与人员:XXXXXX事业部研发人员
  • 会议时间:XXX年XX月XX日 PM 4:30
  • 会议地点:大会议室
  • 会议时长:1个小时50分钟
  • 课题讲义:k8s-study-share

技术分享内容

  • 了解应用部署模式变迁
    • 所在领域的位置和作用
    • 该事物发展的历程和规律
    • 引入微服务&云原生应用概念
  • 快速了解 k8s ,有一个整体概念和认知;以及与Docker的区别和联系
  • 大概了解 kubernetes 的架构以及常用组件
  • 根据实际运用中常见需求讲解 kubernetes 的功能特性
  • 列举需求场景,并现场演示解决方案的样例

前言

  • 接触三个多月,一些浅显的认知,希望让大家对 k8s 有一个概念和认知,感兴趣的同学可以下去学习;当下容器技术,云原生蓬勃发展;

  • 产品架构升级改造,之后能够有效的沟通和对接;对 k8s 了解后,减少沟通成本,加快产品架构的升级改造

  • 先从整体上看一下 Kubernetes 的一些理念和基本架构, 然后从网络、 资源管理、存储、服务发现、负载均衡、高可用、rolling upgrade、安全、监控等方面向大家简单介绍 Kubernetes 的这些主要特性

  • 主要目的是帮助大家快速理解 Kubernetes 的主要功能,今后在研究和使用这个具的时候有所参考和帮助

应用部署模式变迁

kubernetes学习:

  • 所在领域的位置和作用
  • 该事物发展的历程和规律,Kubernetes 的出现就是应用部署运行模式在外部条件需求变更的情况下,演化出来的结果

物理机:程序直接在物理机上直接部署,构建和运行;大多数情况下,一台物理机上可能只部署一个应用,成本很高,但资源利用率却不高;针对业务需求变化的响应周期非常长;

虚拟化:提升资源利用率 & 降低使用成本;

  • 初期:基础计算单元变为VM虚拟机,服务端应用的构建、部署和运行逐步迁移到虚拟机VM上了
  • 成熟期:openstark发布

容器化:以docker为代表的内核容器技术形成了一种标准的镜像格式;与VM相比,容器具有开发交付流程操作对象同步、执行更为高效资源占用更为集约等优势;计算基本单元由虚拟机变为了容器,越来越多应用的构建、部署与运行选择在容器中进行

云原生模式:随着容器技术的岀现以及应用所面临的外部环境的变化,云原生逐渐成为一种应用云化开发、部署和运行的主流方式;核心:借助容器管理自动化平台进行动态编排和资源优化利用

k8s 的架构

像大多数的分布式系统,K8S 集群至少需要一个主节点 (Master) 和多个计算节点(Node)

  • 主节点主要用于暴露 API,调度部署,和节点的管理。
  • 计算节点运行一个容器运行环境,如 Docker 或 rkt,同时运行一个 K8S 的代理用于同主节点通信。计算节点也会运行一些额外的组件,像记录日志,节点监控,服务发现等等。计算节点是 K8S 集群中真正工作的节点

master节点

主节点运行组件:

  • Api Server 提供了资源操作的唯一入口,并提供认证、授权、访问控制、API 注册和发现等机制;
  • Scheduler 负责资源的调度,按照预定的调度策略将 Pod 调度到相应的node节点上;
  • etcd 是 Kubernetes 提供默认的存储系统,保存所有集群的数据和状态;
  • Controller manager 负责维护集群的状态,比如故障检测、自动扩展、滚动更新等

Node 节点

  • kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡;

  • Docker 为容器的运行环境

  • kubelet 负责维护容器的生命周期,同时也负责 Volume(CVI)和网络(CNI)的管理,一般运行在所有的节点

功能特性

资源调度

  • 使用集群,要想屏蔽底层的细节,增强可靠性和稳定性,从而需要创建集群;
  • 统一对外提供接口,无须进行各种复杂的调用;提供更好的可靠性,服务器宕机那么频繁,物理磁盘那么容易损坏,无须担心,集群统一进行调配;提供更好的性能

健康检查 & 故障恢复

  • 节点故障

    一般来说,在我们面对数量庞大的部署实例的时候, 最头疼的就是如果环境不稳定,比如节点故障,或者进程本身故障的时候,我们该如何维护这些部署实例。 在部署实例还比较少的时候这些都不是问题,我们人肉维护都是可以接受的。 但是当我们有微服务的时候,有多套测试环境的时候,数以百计的部署实例会让所有维护人员都疯掉。 尤其是有些服务的故障可能是很临时性的,比如仅仅是进程 oom 了,或者部署的当前节点发生了什么故障。 并不是进程本身的问题。可能只需要重启或者换个节点重新部署就能解决的问题。那这时候 k8s 的调度能力就起到了很大的作用。 首先 k8s 能够自动监控每个节点的健康状况, 如果 A 节点发生了故障,k8s 会监控到 A 节点是不健康的状态, 那么原来启动在 A 节点上的服务,都会自动的漂移到其他的可用节点上重新启动,来保证我们环境的可用性。 这是节点上的健康检查 。

  • 部署实例故障

    同时我们也有用部署实例 pod 的健康检查, 在 k8s 中,启动一个pod时,可以为它配置相应的健康检查策略,检测资源使用和自定义进程检测指标。当pod出现异常时候,k8s 都会自动的检测到并在合适的节点上根据重启策略重启该 pod 实例,这其中不会有任何的人工操作。这种故障恢复能力,是在我们面对大规模测试环境中要拥有的重要能力

  • 对线上业务来说,保证服务的正常稳定是重中之重,对故障服务的及时处理避免影响业务以及快速恢复一直是开发运维的难点。Kubernetes 提供了健康检查服务,对于检测到故障服务会被及时自动下线,以及通过重启服务的方式使服务自动恢复

  • 如果服务的健康检查(readiness)失败,故障的服务实例从 service endpoint 中下线,外部请求将不会再转发到该服务上,一定程度上保证正在提供的服务的正确性,如果服务自我恢复了(比如网络问题),会自动重新加入 service endpoint 对外提供服务。

  • 另外,如果设置了 Container(liveness)的探针,对故障服务的 Container(liveness)的探针同样会失败,container 会被 kill 掉,并根据原设置的 container 重启策略,系统倾向于在其原所在的机器上重启该 container、或其他机器重新创建一个 pod

  • 整个服务实现了自身可用与自动恢复

资源监控

  • 监控是成功运行基础设施的关键之一,它是可靠性等级的基础

  • Prometheus 开源监控告警解决方案,主要用于抓取数据和存储时序数据,另外还提供查询和 Alert Rule 配置管理;用于告警通知管理的 alertmanager

服务发现 & 负载均衡

  • 服务发现:由于 Kubernetes 的调度机制,在 Kubernetes 中,Pod 的 IP 不是固定的。如果其它程序需要访问这个 Pod,要怎么知道这个 Pod 的 IP 呢?
  • 负载均衡:由于 Deployment 管理着多个 Pod 的副本,如果其它程序需要访问这些 Pod,显然需要一个 proxy 为这些 Pod 做负载均衡。
  • 外部路由:如果应用程序运行在 Kubernetes 外部,如何访问 Kubernetes 内部的 Pod 呢?

扩容缩容

  • 在实际生产系统中,我们经常会遇到某个服务需要扩容的场景,也可能会遇到由于资源紧张或者工作负载降低而需要减少服务实例数的场景

  • Pod 水平自动伸缩,通过此功能,只需简单的配置,集群便可以利用监控指标(cpu 使用率等)自动的扩容或者缩容服务中 Pod 数量,当业务需求增加时,系统将为您无缝地自动增加适量容器 ,提高系统稳定性

滚动更新回滚

用户需求:需要应用始终正常运行,开发人员每天需要部署新的版本*(一个简单例子,大家在玩游戏时常常碰到这类公告:8 月 8 日凌晨:2 点 - 6 点服务升级,暂停所有服务…..)*

  • Kubernetes 提供的滚动更新机制每次更新一小部分,零停机,实现了业务的连续性;回滚机制则是保证了每次更新应用的时候都会记录下当前的配置,保存为一个 revision,这样就可以回滚到某个特定的 revision
  • 将应用从一个环境升级到另一个环境(通过容器镜像更新)
  • 回滚到之前的版本
  • 持续集成和持续交付应用的零停机

配置管理

  • 在几乎所有的应用开发中,都会涉及到配置文件的变更,比如说在 web 的程序中,需要连接数据库,缓存甚至是队列等等。应用开发上线过程需要分别部署到开发环境、测试环境、预发布环境等多个环境。而每一个环境都要定义其独立的各种配置。如何对配置文件进行管理,是应用程序管理的重要内容。

  • ConfigMap 使注入基于环境的配置成为可能,同时使容器镜像在多个环境中保持一致。这些可以通过安装卷或环境变量(env)来注入,并将这些值存储在 key/value 格式中

  • Kubernetes 中通过 ConfigMap 资源管理应用程序的配置信息。ConfigMap 本质上是一个基于 key/value 键值方式存储的一段文本。Kubernetes 支持三种使用方式:

    1. 设置成容器的环境变量。
    2. 在容器的启动参数中使用。
    3. 将 key 中的内容,作为文件挂载到容器某个目录下。

存储挂载

  • 大家都知道容器本身一般不会对数据进行持久化处理,在 Kubernetes 中,容器异常退出,kubelet 也只是简单的基于原有镜像重启一个新的容器。另外,如果我们在同一个 Pod 中运行多个容器,经常会需要在这些容器之间进行共享一些数据。Kuberenetes 的 Volume 就是主要来解决上面两个基础问题的

  • Pods 本质是短暂的——任何储存在 pod 或容器中的信息都会丢失。为了存储数据,一个持久的系统是必需的,即使在一个 pod 被杀死或重新调度之后,如 Amazon Elastic Block Storage (EBS),谷歌 GCE PD,或一个分布式文件系统,如网络文件系统 (NFS) 或 Gluster 文件系统(GFS)

  • 卷的概念;Kubernetes 支持多种类型的 volume,并且 pod 可以同时使用多种类型的 volume

    • emptyDir:当 Pod 被分配到一个 Node 上时,emptyDir volume 就第一次被创建,只要 Pod 还运行在该 Node 上,该 volume 就一直存在
    • hostPathhostPath volume 映射 node 文件系统中的文件或者目录到 pod 里
    • rbd、nfs、cephfs 等常见的存储卷类型

无状态服务 & 有状态服务

  • 无状态服务
    • 是指该服务运行的实例不会在本地存储需要持久化的数据,并且多个实例对于同一个请求响应的结果是完全一致的;当访问该服务的请求到达服务一端后,Service 负载均衡后会找到一个容器实例来完成该请求的响应,这类服务的实例可能会因为一些原因停止或者重新创建(如扩容时),这时,这些停止的实例里的所有信息(除日志和监控数据外)都将丢失 (重启容器即会丢失)
  • 有状态服务
    • 是指该服务的实例可以将一部分数据随时进行备份,并且在创建一个新的有状态服务时,可以通过备份恢复这些数据,以达到数据持久化的目的
      • 要求稳定的网络身份。Headless Service 为集群内部每个节点提供统一的 DNS 名称,同时不需要 ClusterIP,通过ClusterIp:None指定
      • 要求稳定的存储,这个可以通过 PV 实现
      • 有序部署,有序扩展,有序伸缩,有序删除
Share on

睡沙发の沙皮狗
WRITTEN BY
睡沙发の沙皮狗
👨‍💻 Backend Developer/📚 Learner/🚀 Opensource enthusiast

 

What's on this Page