Kubernetes（K8S）基础

简介

  • Kubernetes (K8S) 是一个为 容器化 应用提供集群部署和管理的开源工具，由 Google 开发。K8S官方文档
  • Kubernetes 这个名字源于希腊语，意为“舵手”或“飞行员”。
    k8s 这个缩写是因为 k 和 s 之间有八个字符的关系。 Google 在 2014 年开源了 Kubernetes 项目。
  • Kubernetes 的大部分组件都是用 Go 语言编写的，包括：API Server、Scheduler、Controller Manager、kubelet、kube-proxy、etcd 等等

主要特性

  1. 高可用，不宕机，自动灾难恢复
  2. 灰度更新，不影响业务正常运转
  3. 一键回滚到历史版本
  4. 方便的伸缩扩展（应用伸缩，机器加减）、提供负载均衡
  5. 有一个完善的生态

不同的应用部署方案

  1. 传统部署方式应用直接在物理机上部署，机器资源分配不好控制，出现Bug时，可能机器的大部分资源被某个应用占
    用，导致其他应用无法正常运行，无法做到应用隔离。
  2. 虚拟机部署在单个物理机上运行多个虚拟机，每个虚拟机都是完整独立的系统，性能损耗大。
  3. 容器部署所有容器共享主机的系统，轻量级的虚拟机，性能损耗小，资源隔离，CPU和内存可按需分配

什么时候需要K8S

  1. 当你的应用只是跑在一台机器，直接一个 docker + docker-compose 就够了，方便轻松；
  2. 当你的应用需要跑在 3，4 台机器上，你依旧可以使用每台机器单独配置运行环境 + 负载均衡器；
  3. 当你的应用需要跑在 10，20 台机器上，可以使用Docker+Swarm部署;
  4. 当你应用访问数不断增加，机器逐渐增加到几十台、上百台、上千台时，每次加机器、软件更新、版本
    回滚，都会变得非常麻烦，这个时候就可以使用K8s。

　　Kubernetes 可以为我们提供集中式管理集群的方法，加机器、版本升级、版本回滚，那都是一个命令
就搞定的事，不停机的灰度更新，确保高可用、高性能、高扩展。

　　国内很多云厂商对K8s都有很好的支持，当你的并发量比较大的时候你可以动态创建k8s节点（服务
器），当您的并发量高峰过去以后你又可以动态的减少K8s节点（服务器）。

K8S集群架构

在一个 Kubernetes 集群中，通常有多个 Node 节点，每个节点上可以运行多个 Pod。

一个 Pod 是 Kubernetes 中的最小工作单元，它可以包含一个或多个容器，但是它们共享同一个网络命名空间和存储卷。Pod 可以运行在 Node 节点上，但不同的 Pod 可能分配到不同的 Node 节点上。

 

master

主节点，控制平台，不需要很高性能，不跑任务，通常一个就行了，也可以开多个主节点来提高集群可用度。

worker

工作节点，可以是虚拟机或物理计算机，任务都在这里跑，机器性能需要好点；通常都有很多个，可以不断加机器扩大集群。

重要概念

Pod

Master 节点主要包括 API Server、etcd、Controller Manager 和 Scheduler 四个核心组件。

Node 节点主要包括 Kubelet、kube-proxy、容器运行时（如 Docker）等组件。Kubelet 和 kube-proxy 在每个 Node 节点上运行，负责监控容器的状态并与 Master 节点通信。

在 Node 节点上运行的每个容器都是一个 Pod，Pod 可以包含一个或多个容器。

 

亲和性 (affinity)规则指定pod应该被分配到哪些节点上，反亲和性规则 (anti-affinity) 规则可用于指定 pod 应该避免被分配到哪些节点上，调度器会遵循这些规则来选择节点。

豆荚，K8S 调度、管理的最小单位，一个 Pod 可以包含一个或多个容器，每个 Pod 有自己的虚拟IP。一个工作节点可以有多个 pod，主节点会考量负载自动调度 pod 到哪个节点运行。

如何分配Pod

Kubernetes 控制器和调度器通过一种算法来计算出可以为新的 Pod 分配资源的最佳节点，并将 Pod 调度到该节点上运行。这个算法被称为调度器算法，通常包括以下几个步骤：

  1. 首先，调度器会检查集群中所有节点的资源（如 CPU、内存、存储）以及当前可用性。

  2. 接着，调度器会对每个节点进行评分，根据评分决定哪个节点最适合运行该 Pod。评分可能包括几个因素，如节点资源使用率、亲和性和反亲和性规则等。

  3. 调度器根据评分确定最佳节点，将 Pod 调度到该节点上。

Kubernetes 调度器支持多种算法，比如默认的 Round Robin 或 Random 算法，还有 NodeSelector、NodeAffinity、PodAffinity 和 PodAntiAffinity 等高级算法，这些算法可以让用户更好地控制 Pod 的调度和位置。

Deployment

pod是最小的控制单元,但是k8s很少直接控制pod,一般都是通过pod控制器来完成 ，Deployment
就是k8s中用来管理发布pod的控制器，在开发的过程中使用非常频繁 。
通俗的讲，Deployment 主要是解决了pod的编排问题。
Deployment能帮助我们做什么事情？

  • 定义一组Pod的期望数量，controller会维持Pod数量与期望数量一致
  • 配置Pod发布方式，controller会按照给定策略更新Pod，保证更新过程中不可用的Pod数量在限定范围内。
  • 如果发布有问题，支持一键回滚

 

Service

Docker Swarm中使用ingress Network实现了负载均衡的功能，K8s中实现负载均衡需要借助Service。
Service是一种可以访问 Pod逻辑分组的策略， Service通常是通过 Label Selector访问 Pod组 。

Kubernetes 的组件

Kubernetes 的控制面包含着 kube-apiserver、kube-scheduler、kube-controller-manager 这三大组件，我们也称为 Kubernetes 的三大件。下面逐一来讲一下它们的功能及作用。

kube-apiserver

首先来看 kube-apiserver，它 是整个 Kubernetes 集群的“灵魂”，是信息的汇聚中枢，提供了所有内部和外部的 API 请求操作的唯一入口。同时也负责整个集群的认证、授权、访问控制、服务发现等能力。

用户可以通过命令行工具 kubectl 和 APIServer 进行交互，从而实现对集群中进行各种资源的增删改查等操作。APIServer 跟 BorgMaster 非常类似，会将所有的改动持久到 Etcd 中，同时也保存着一份内存拷贝。

这也是为什么我们希望 Master 节点可以性能好、资源规格大，尤其是当集群规模很大的时候，APIServer 的吞吐量以及占用的 CPU 和内存都要很大。APIServer 还提供很多可扩展的能力，方便增强自己的功能。

Kube-Controller-Manager

Kube-Controller-Manager，它负责维护整个 Kubernetes 集群的状态，比如多副本创建、滚动更新等。Kube-controller-manager 并不是一个单一组件，内部包含了一组资源控制器，在启动的时候，会通过 goroutine 拉起多个资源控制器。这些控制器的逻辑仅依赖于当前状态，因为在分布式系统中没办法保证全局状态的同步。

同时在实现的时候避免使用过于复杂的状态机，因此每个控制器仅仅对自己对应的资源对象做操作。而且控制器做了很多容错处理，比如增加 retry 机制等。

Kube-scheduler

Kube-scheduler，它的工作简单来说就是监听未调度的 Pod，按照预定的调度策略绑定到满足条件的节点上。这个工作虽说看起来是三大件中最简单的，但是做的事情可一点不少。

 

除了上述这些核心组件外，通常我们还会在 Kubernetes 集群中部署一些 Add-on 组件，常见的有：

  1. CoreDNS 负责为整个集群提供 DNS 服务；

  2. Ingress Controller 为服务提供外网接入能力；

  3. Dashboard 提供 GUI 可视化界面；

  4. Fluentd + Elasticsearch 为集群提供日志采集、存储与查询等能力。

Master 和 Node 的交互方式

在这一点上，Kubernetes 和 Borg 完全相反。Kubernetes 中所有的状态都是采用上报的方式实现的。APIServer 不会主动跟 Kubelet 建立请求链接，所有的容器状态汇报都是由 Kubelet 主动向 APIServer 发起的。

当集群资源不足的时候，可以按需增加Node 节点。一旦启动 Kubelet 进程以后，它会主动向 APIServer 注册自己，这是 Kubernetes 推荐的 Node 管理方式。当然你也可以在Kubelet 启动参数中去掉自动注册的功能，不过一般都是默认开启这个模式的。

一旦新增的 Node 被 APIServer 纳管进来后，Kubelet 进程就会定时向 APIServer 汇报“心跳”，即汇报自身的状态，包括自身健康状态、负载数据统计等。当一段时间内心跳包没有更新，那么此时 kube-controller-manager 就会将其标记为NodeLost（失联）。这也是 Kubernetes 跟 Borg 有区别的一个地方。

Kubernetes 中各个组件都是以 APIServer 为中心，通过松耦合的方式进行。借助声明式 API，各部件通过 watch 的机制就可以根据各个对象的变化，很快地做出相应的处理操作。

 

虽说 Kubernetes 跟 Borg 系统有不少差异，但是总体架构还是相似的。从Kubernetes的架构以及各组件的工作模式可以看到，Kubernetes 系统在设计的时候很注重容错性和可扩展性。

它假定有发生任何错误的可能，通过 backoff retry、多副本、滚动升级等机制，增强集群的容错性，提高 Kubernetes 系统的稳定性。同时对各个组件增加可扩展能力，保证 Kubernetes 对新功能的接入能力，让人们可以对 Kubernetes 进行个性化定制。

posted @ 2019-07-09 18:25  GJH-  阅读(117)  评论(0)    收藏  举报