k8s基础之概念讲解

目录

• 1 Kubernetes
  • 1.1 简介
  • 1.2 特性
  • 1.3 架构
  • 1.4 组件
    • 1.4.1 Master Node
    • 1.4.2 Work Node
    • 1.4.3 service
    • 1.4.4 Namespace
    • 1.4.5 Volume
  • 1.5 Pod控制器
    • 1.5.1 pod
    • 1.5.2 Pod控制器

1 Kubernetes

1.1 简介

Kubernetes 是一个全新的基于容器技术的分布式架构解决方案，是 Google 开源的一个容器集群管理系统，Kubernetes 简称 K8S，官方文档：https://kubernetes.io/zh/。
Kubernetes 是一个一站式的完备的分布式系统开发和支撑平台，更是一个开放平台，对现有的编程语言、编程框架、中间件没有任何侵入性。
Kubernetes 提供了完善的管理工具，这些工具涵盖了开发、部署测试、运维监控在内的各个环节。Kubernetes 具有完备的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制、多粒度的资源配额管理能力。
Kubernetes是一个轻便的和可扩展的开源平台，用于管理容器化应用和服务。通过Kubernetes能够进行应用的自动化部署和扩缩容。

1.2 特性

Kubernetes的关键特性包括：

• 自动化装箱：在不牺牲可用性的条件下，基于容器对资源的要求和约束自动部署容器。同时，为了提高利用率和节省更多资源，将关键和最佳工作量结合在一起。
• 自愈能力：当容器失败时，会对容器进行重启；当所部署的Node节点有问题时，会对容器进行重新部署和重新调度，保证预期的副本数量；当容器未通过监控检查时，会关闭此容器；直到容器正常运行时，才会对外提供服务。
• 弹性伸缩：通过简单的命令、用户界面或基于CPU的使用情况，能够对应用进行扩容和缩容，保证应用业务高峰并发时的高可用性；业务低峰时回收资源，以最小成本运行服务
• 服务发现和负载均衡：开发者不需要使用额外的服务发现机制，就能够基于Kubernetes进行服务发现和负载均衡。K8S 为多个容器提供一个统一访问入口（内部IP地址和一个DNS名称），并且负载均衡关联的所有容器，使得用户无需考虑容器IP问题
• 自动发布和回滚：Kubernetes能够程序化的发布应用和相关的配置。如果发布有问题，Kubernetes将能够回归发生的变更。
  K8S采用滚动更新策略更新应用，一次更新一个Pod，而不是同时删除所有Pod，如果更新过程中出现问题，将回滚更改，确保升级不影响业务。
• 保密和配置管理：在不需要重新构建镜像的情况下，可以部署和更新保密和应用配置。
  管理机密数据和应用程序配置，而不需要把敏感数据暴露在镜像里，提高敏感数据安全性。并可以将一些常用的配置存储在K8S中，方便应用程序使用
• 存储编排：挂载外部存储系统，无论是来自本地存储，公有云（例如：GCP和AWS），还是网络存储(例如：NFS、iSCSI、Gluster、Ceph、Cinder和Floker等)，都作为集群资源的一部分使用，极大提高存储使用灵活性
• 批处理：提供一次性任务，定时任务；满足批量数据处理和分析的场景

1.3 架构

Kubernetes 集群架构以及相关的核心组件如下图所示：一个 Kubernetes 集群一般包含一个 Master 节点和多个 Node 节点，一个节点可以看成是一台物理机或虚拟机

1.4 组件

1.4.1 Master Node

Kubernetes属于主从分布式架构，主要由Master Node和Worker Node组成，以及包括客户端命令行工具Kubectl和其它附加项。

Master Node：作为控制节点，对集群进行调度管理，Master主要由三部分构成：

• kube-apiserver：相当于 K8S 的网关，它负责暴露Kubernetes API，所有的指令请求都必须经过 Api Server。
  集群的统一入口，各组件协调者，以 HTTP Rest 提供接口服务，所有对象资源的增、删、改、查和监听操作都交给 apiserver 处理后再提交给 Etcd 存储
  接收用户输入的命令，提供认证、授权、API注册和发现等机制
• kube-scheduler：使用调度算法，把请求资源调度到某个 Node 节点。
  根据调度算法为新创建的 Pod 选择一个 Node 节点，可以任意部署，可以部署在同一个节点上，也可以部署在不同的节点上。
  调度器根据资源需求、策略约束、负载平衡等因素做出决策。
• kube-controller-manager：维护 K8S 资源对象（CRUD：添加、删除、更新、修改）;
  K8S 里所有资源对象的自动化控制中心，处理集群中常规后台任务，一个资源对应一个控制器，而 controller-manager 就是负责管理这些控制器的
  • Kubernetes Controller Manager：负责运行控制器，这些控制器是用于处理集群中常见的任务的后台线程。例如，Replication Controller确保集群中的副本数量与用户定义的副本数量相匹配。
  • Cloud Controller Manager：负责与底层云提供商进行交互，以便在云基础设施上管理资源
• etcd 存储资源对象：可以服务注册、发现等等
  一个分布式的，一致的 key-value 存储，主要用途是共享配置和服务发现，保存集群状态数据，比如 Pod、Service 等对象信息
• Kubectl：命令行配置工具

1.4.2 Work Node

除了 Master，K8S 集群中的其它机器被称为 Node 节点，Node 节点是 K8S 集群中的工作负载节点，每个 Node 都会被 Master 分配一些工作负载，当某个 Node 宕机时，其上的工作负载会被 Master 自动转移到其它节点上去。
Worker Node：作为真正的工作节点，运行业务应用的容器；Worker Node主要包含五部分:

• Docker Engine：是运行容器的基础环境，容器引擎，负责本机的容器创建和管理工作
• Kubelet：是Master 在 Node 节点上的 Agent(代理)，与 Master 密切协作，管理本机运行容器的生命周期，负责 Pod 对应的容器的创建、启停等任务，实现集群管理的基本功能。
  在 Node 节点上执行的资源操作，Scheduler 把请求交给Api ，然后 Api Sever 再把信息指令数据存储在 ETCD 里，于是 Kubelet 会扫描 ETCD 并获取指令请求，然后去执行
• Kube-proxy：代理服务，起到负载均衡作用，在 Node 节点上实现 Pod 网络代理，实现 Kubernetes Service 的通信，维护网络规则和四层负载均衡工作
• Fluentd：采集日志

1.4.3 service

在kubernetes中，pod是应用程序的载体，我们可以通过pod的ip来访问应用程序，但是pod的ip地址不是固定的，这也就意味着不方便直接采用pod的ip对服务进行访问。
为了解决这个问题，kubernetes提供了Service资源，Service会对提供同一个服务的多个pod进行聚合，并且提供一个统一的入口地址。通过访问Service的入口地址就能访问到后面的pod服务。
Service在很多情况下只是一个概念，真正起作用的其实是kube-proxy服务进程，每个Node节点上都运行着一个kube-proxy服务进程。当创建Service的时候会通过api-server向etcd写入创建的service的信息，而kube-proxy会基于监听的机制发现这种Service的变动，然后它会将最新的Service信息转换成对应的访问规则。

Service 是一种抽象，它定义了一组Pod 的访问策略。Service 可以运行在master节点和worker节点上。Service的主要目的是为Pod提供稳定的IP地址和DNS名称，以便其他Pod可以访问它们。Service可以将流量负载均衡到后端的Pod，从而实现高可用性和伸缩性。
Service 定义了一个服务的访问入口，通过 Label Selector 与 Pod 副本集群之间“无缝对接”，定义了一组 Pod 的访问策略，防止 Pod 失联。
创建 Service 时，K8S会自动为它分配一个全局唯一的虚拟 IP 地址，即 Cluster IP。服务发现就是通过 Service 的 Name 和 Service 的 ClusterIP 地址做一个 DNS 域名映射来解决的

Service常用类型：

• ClusterIP：默认值，它是Kubernetes系统自动分配的虚拟IP，只能在集群内部访问
• NodePort：将Service通过指定的Node上的端口暴露给外部，通过此方法，就可以在集群外部访问服务
• LoadBalancer：使用外接负载均衡器完成到服务的负载分发，注意此模式需要外部云环境支持
• ExternalName： 把集群外部的服务引入集群内部，直接使用

1.4.4 Namespace

Namespace ，命名空间多用于实现多租户的资源隔离。Namespace 通过将集群内部的资源对象 分配 到不同的 Namespace 中，形成逻辑上分组的不同项目、小组或用户组。
K8S 集群在启动后，会创建一个名为 default 的 Namespace，如果不特别指明 Namespace，创建的 Pod、RC、Service 都将被创建到 default 下。
当我们给每个租户创建一个 Namespace 来实现多租户的资源隔离时，还可以结合 K8S 的资源配额管理，限定不同租户能占用的资源，例如 CPU 使用量、内存使用量等
Namespace 是一个逻辑概念，用于将集群内的资源进行隔离和分组。Namespace 存在于整个 Kubernetes 集群中，而不仅仅是在 master 节点或 worker 节点。当在 Kubernetes 集群中创建一个 Namespace 时，它将在 master 节点上的 API server 中进行注册，而在实际运行中，Namespace 中的资源（如 Pod、Service 等）可以分布在多个 worker 节点上。因此，可以说 Namespace 既存在于 master 节点，也存在于 worker 节点。

1.4.5 Volume

为了持久化保存容器的数据，kubernetes引入了Volume的概念。
Volume是Pod中能够被多个容器访问的共享目录，它被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下，kubernetes通过Volume实现同一个Pod中不同容器之间的数据共享以及数据的持久化存储。Volume的生命容器不与Pod中单个容器的生命周期相关，当容器终止或者重启时，Volume中的数据也不会丢失。

kubernetes的Volume支持多种类型，比较常见的有下面几个：

• 简单存储：EmptyDir、HostPath、NFS
• 高级存储：
  • PV（Persistent Volume）：是持久化卷的意思，是kubernetes管理员维护，是对底层的共享存储的一种抽象。一般情况下PV由kubernetes管理员进行创建和配置，它与底层具体的共享存储技术有关，并通过插件完成与共享存储的对接。
  • PVC（Persistent Volume Claim）：是持久卷声明的意思，是kubernetes用户维护,是用户对于存储需求的一种声明。换句话说，PVC其实就是用户向kubernetes系统发出的一种资源需求申请。
• 配置存储：ConfigMap、Secret

1.5 Pod控制器

1.5.1 pod

Pod是Kubernetes 管理的基本单元（最小单元)，Pod 内部是容器。Kubernetes 不直接管理容器，而是管理 Pod，它是WorkNode中一个组件
Pod 是 K8S 中最重要也是最基本的概念，Pod 是最小的部署单元，是一组容器的集合。每个 Pod 都由一个特殊的根容器 Pause 容器，以及一个或多个紧密相关的用户业务容器组成。
Pause 容器作为 Pod 的根容器，以它的状态代表整个容器组的状态。K8S 为每个 Pod 都分配了唯一的 IP 地址，称之为 Pod IP。Pod 里的多个业务容器共享 Pause 容器的IP，共享 Pause 容器挂载的 Volume

Pod 是 kubernetes 的最小管理单元，在 kubernetes 中，按照 pod 的创建方式可以将其分为两类：

• 自主式pod：kubernetes直接创建出来的Pod，这种pod删除后就没有了，也不会重建
• 控制器创建的pod：kubernetes 通过控制器创建的pod，这种pod删除了之后还会自动重建

pod 的生命周期：

• pod创建过程
• 运行初始化容器（init container）过程
• 运行主容器（main container）
• 容器启动后钩子（post start），容器终止前钩子（pre stop）
• 容器的存活性探测（liveness probe），就绪性探测（readiness probe）
• pod终止过程
  
  在整个生命周期中，Pod会出现5种状态（相位），分别如下：
• 挂起（Pending）：apiserver已经创建了pod资源对象，但它尚未被调度完成或者仍处于下载镜像的过程中
• 运行中（Running）：pod已经被调度至某节点，并且所有容器都已经被kubelet创建完成
• 成功（Succeeded）：pod中的所有容器都已经成功终止并且不会被重启
• 失败（Failed）：所有容器都已经终止，但至少有一个容器终止失败，即容器返回了非0值的退出状态
• 未知（Unknown）：apiserver无法正常获取到pod对象的状态信息，通常由网络通信失败所导致

1.5.2 Pod控制器

Pod控制器是管理pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod资源在运行中出现故障，它会基于指定策略重新编排Pod。

常见的有Pod控制器有下面这些：

• ReplicationController：比较原始的pod控制器，已经被废弃，由ReplicaSet替代
• ReplicaSet(RS)：保证副本数量一直维持在期望值，并支持 pod 数量扩缩容，镜像版本升级
  ReplicaSet的主要作用是保证一定数量的pod正常运行，它会持续监听这些Pod的运行状态，一旦Pod发生故障，就会重启或重建。同时它还支持对pod数量的扩缩容和镜像版本的升降级
• Deployment：通过控制 ReplicaSet 来控制 Pod，并支持滚动升级、回退版本
  为了更好的解决服务编排的问题，kubernetes在V1.2版本开始，引入了Deployment控制器。值得一提的是，这种控制器并不直接管理pod，而是通过管理ReplicaSet来简介管理Pod，即：Deployment管理ReplicaSet，ReplicaSet管理Pod。所以Deployment比ReplicaSet功能更加强大。
• Horizontal Pod Autoscaler(HPA)：可以根据集群负载自动水平调整Pod的数量，实现削峰填谷
  我们可以实现通过手工执行kubectl scale命令实现Pod扩容或缩容，但是这显然不符合Kubernetes的定位目标--自动化、智能化。 Kubernetes期望可以实现通过监测Pod的使用情况，实现pod数量的自动调整，于是就产生了Horizontal Pod Autoscaler（HPA）这种控制器。
  HPA可以获取每个Pod利用率，然后和HPA中定义的指标进行对比，同时计算出需要伸缩的具体值，最后实现Pod的数量的调整。其实HPA与之前的Deployment一样，也属于一种Kubernetes资源对象，它通过追踪分析RC控制的所有目标Pod的负载变化情况，来确定是否需要针对性地调整目标Pod的副本数，这是HPA的实现原理。
• DaemonSet：在集群中的指定 Node上运行且仅运行一个副本，一般用于守护进程类的任务。
  DaemonSet类型的控制器可以保证在集群中的每一台（或指定）节点上都运行一个副本。一般适用于日志收集、节点监控等场景。也就是说，如果一个Pod提供的功能是节点级别的（每个节点都需要且只需要一个），那么这类Pod就适合使用DaemonSet类型的控制器创建
  DaemonSet控制器的特点：
  • 每当向集群中添加一个节点时，指定的 Pod 副本也将添加到该节点上
  • 当节点从集群中移除时，Pod 也就被垃圾回收了
• Job：它创建出来的pod只要完成任务就立即退出，不需要重启或重建，用于执行一次性任务。
  Job，主要用于负责批量处理(一次要处理指定数量任务)短暂的一次性(每个任务仅运行一次就结束)任务。
  Job特点如下：
  • 当Job创建的pod执行成功结束时，Job将记录成功结束的pod数量
  • 当成功结束的pod达到指定的数量时，Job将完成执行
• Cronjob：它创建的Pod负责周期性任务控制，不需要持续后台运行
  CronJob控制器以Job控制器资源为其管控对象，并借助它管理pod资源对象，Job控制器定义的作业任务在其控制器资源创建之后便会立即执行，但CronJob可以以类似于Linux操作系统的周期性任务作业计划的方式控制其运行时间点及重复运行的方式。也就是说，CronJob可以在特定的时间点(反复的)去运行job任务
• StatefulSet：管理有状态应用