Kubernetes基础

Posted 2022-02-02 码出未来_远

Kubernetes基础

文章目录

• Kubernetes基础
• Pod是什么？
• • • Pod的作用
    • Pod控制器
  • Label
  • • Label
    • 为什么要用Label
    • Label选择器
  • Node
  • Kubernetes集群架构
  • • master
    • node（worker节点）
  • Kubernetes的特性
  • • • • • 自动化
          • 以服务为中心
          • 高可用
          • 滚动更新
          • 自我修复
          • 弹性伸缩
          • 自动部署和回滚
          • 服务发现和负载均衡
          • 机密和配置管理
          • 存储编排
          • 批处理
  • 网络模型

Pod是什么？

Pod是Kubernetes中能够创建和部署（运行）的最小逻辑单元（原子单元），是Kubernetes集群中的一个应用实例，总是部署在同一个节点Node上。Pod中包含了一个或多个容器，还包括了存储、网络等各个容器共享的资源。Pod支持多种容器环境，Docker则是最流行的容器环境。

• 单容器Pod，最常见的应用方式。
• 多容器Pod，对于多容器Pod，Kubernetes会保证所有的容器都在同一台物理主机或虚拟主机中运行。多容器Pod是相对高阶的使用方式，除非应用耦合特别严重，一般不推荐使用这种方式。一个Pod内的容器共享IP地址和端口范围，容器之间可以通过 localhost 互相访问。

Pod并不提供保证正常运行的能力，因为可能遭受Node节点的物理故障、网络分区等等的影响，整体的高可用是Kubernetes集群通过在集群内调度Node来实现的。通常情况下我们不要直接创建Pod，一般都是通过Controller来进行管理，但是了解Pod对于我们熟悉控制器非常有好处。

Pod的作用

Pod的作用

• Pod做为一个可以独立运行的服务单元，简化了应用部署的难度，以更高的抽象层次为应用部署管提供了极大的方便。
• Pod做为最小的应用实例可以独立运行，因此可以方便的进行部署、水平扩展和收缩、方便进行调度管理与资源的分配。
• Pod中的容器共享相同的数据和网络地址空间，Pod之间也进行了统一的资源管理与分配。

Pod控制器

Pod控制器是Pod启动的一种模板，用来保证在k8s里启动的Pod应始终按照人们的预期运行（副本数、生命周期、健康状态检查…）

k8s内提供了众多的Pod控制器，常用的有：

• Deployment
• DaemonSet
• ReplicaSet
• StatefulSet
• Job
• Cronjob

Label

Label

标签（Label）是附加在Kubernetes对象上的一组名值对，其意图是按照对用户有意义的方式来标识Kubernetes对象，同时，又不对Kubernetes的核心逻辑产生影响。标签可以用来组织和选择一组Kubernetes对象。您可以在创建Kubernetes对象时为其添加标签，也可以在创建以后再为其添加标签。每个Kubernetes对象可以有多个标签，同一个对象的标签的 Key 必须唯一

• 标签是k8s特色的管理方式，便于分类管理资源对象。
• 一个标签可以对应多个资源，一个资源也可以有多个标签，他们是多对多的关系。
• 一个资源拥有多个标签，可以实现不同维度的管理
• 标签的组成：key=value
• 与标签类似的还有一种“注解”（annotations）

为什么要用Label

使用标签，用户可以按照自己期望的形式组织 Kubernetes 对象之间的结构，而无需对 Kubernetes 有任何修改。

应用程序的部署或者批处理程序的部署通常都是多维度的（例如，多个高可用分区、多个程序版本、多个微服务分层）。管理这些对象时，很多时候要针对某一个维度的条件做整体操作，例如，将某个版本的程序整体删除，这种情况下，如果用户能够事先规划好标签的使用，再通过标签进行选择，就会非常地便捷。

Label选择器

与 name 和 UID 不同，标签不一定是唯一的。通常来讲，会有多个Kubernetes对象包含相同的标签。通过使用标签选择器（label selector），用户/客户端可以选择一组对象。标签选择器（label selector）是 Kubernetes 中最主要的分类和筛选手段。

Kubernetes api server支持两种形式的标签选择器，equality-based 基于等式的 和 set-based 基于集合的。标签选择器可以包含多个条件，并使用逗号分隔，此时只有满足所有条件的 Kubernetes 对象才会被选中。

如果使用空的标签选择器或者不指定选择器，其含义由具体的 API 接口决定。

• 给资源打上标签后，可以使用标签选择器过滤指定的标签
• 标签选择器目前有两个：基于等值关系（等于、不等于）和基于集合关系（属于、不属于、存在）

Node

Node（节点）是k8s集群中相对于Master而言的工作主机。Node可以是一台物理主机，也可以是一台虚拟机（VM）。
在每个Node上运行用于启动和管理Pid的服务Kubelet，并能够被Master管理。
在Node上运行的服务进行包括Kubelet、kube-proxy和docker daemon。

Kubernetes集群架构

一个k8s集群包含两个部分：

• master：主控节点
• node：worker节点（工作节点）

master

master本身是不做任何事情的，只提供一些调度等做用，负责管理Node, 控制Node 具体运行什么容器, 同时还承担外部数据访问的角色

master分为三个组件：

• API server：提供认证，授权，访问控制，API注册，发现等机制
• controller-manager：做集群中后台的统一的管理，处理集群中常规的任务，比如：故障检测、自动扩展、滚动更新。
• scheduler：选择合适的node节点来部署，起到节点调度的作用。
• etcd：算不上是组件，算是一个数据库，用来存储集群当中各种的资源，可以部署在任何能够访问到的地方

node（worker节点）

node分为两个组件：

• kubelet：master派到node节点的代表，管理本机容器的各种操作
• kube-proxy：实现Pod的网络代理，用来做服务发现、负载均衡。
• Docker Engin：docker引擎, 负责Node于和容器有关的操作, K8S原生支持Docker作为容器引擎, 如果要使用其他容器引擎则需要使用对应接口集成
• Pod：K8S不是直接运行的容器,而是操作Pod, 把Pod作为原子单元管理,一个Pod里面可能会运行多个容器, Pod里面运行的多个容器被捆绑在一起被统一调度不可分割. 一个Pod的所有容器只能同时运行在一个Node 上

Kubernetes的特性

Kubernetes的特性主要有以下几种：

自动化

• kubernetes有一套自动化机制。可以降低整个集群的运维成本和运维难度
• 通过K8s我们可以实现自动扩容、自动更新、自动部署、自动化管理资源等等。

以服务为中心

• kubernetes以服务为中心，可以让我们抛开系统环境和运行细节，有更多精力去处理逻辑业务。
• 构建在kubernetes上的系统，可以独立运行在物理机、虚拟机、私有云以及公有云。

高可用

• kubernetes会定期进行检查应用实例，这包括对这些实例的数量检查，实例健康状态检查等等。
• kubernetes如果发现有新的应用实例启动，会自动加入负载均衡中。
• kubernetes如果发现有应用实例状态不可用。kubernetes会自动干掉这个问题实例，并重新调度一个新实例。

滚动更新

​ kubernetes可以使整个集群平滑升级（rolling-update），就是说，kubernetes可以在不停止对外服务的 前提下完成应用的更新。在规模比较大的集群中，kubernetes这一特性会非常实用。

自我修复

在节点故障时重新启动失败的容器，替换和重新部署，保证预期的副本数量；杀死健康检查失败的容器，并且在未准备好之前不会处理客户端请求，确保线上服务不中断。

弹性伸缩

使用命令、UI或者基于CPU使用情况自动快速扩容和缩容应用程序实例，保证应用业务高峰并发时的高可用性；业务低峰时回收资源，以最小成本运行服务。

自动部署和回滚

K8S采用滚动更新策略更新应用，一次更新一个Pod，而不是同时删除所有Pod，如果更新过程中出现问题，将回滚更改，确保升级不受影响业务。

服务发现和负载均衡

K8S为多个容器提供一个统一访问入口（内部IP地址和一个DNS名称），并且负载均衡关联的所有容器，使得用户无需考虑容器IP问题。

机密和配置管理

管理机密数据和应用程序配置，而不需要把敏感数据暴露在镜像里，提高敏感数据安全性。并可以将一些常用的配置存储在K8S中，方便应用程序使用。

存储编排

挂载外部存储系统，无论是来自本地存储，公有云（如AWS），还是网络存储（如NFS、GlusterFS、Ceph）都作为集群资源的一部分使用，极大提高存储使用灵活性。

批处理

提供一次性任务，定时任务；满足批量数据处理和分析的场景。

网络模型

Kubernetes的网络模型从内至外由四个部分组成：

Pod内部容器所在的网络
Pod所在的网络
Pod和Service之间通信的网络
外界与Service之间通信的网络

在Kubernetes中要保证容器之间网络互通，网络至关重要。而Kubernetes本身并没有自己实现容器网络，而是通过插件化的方式自由接入进来。在容器网络接入进来需要满足如下基本原则：

Pod无论运行在任何节点都可以互相直接通信，而不需要借助NAT地址转换实现。
Node与Pod可以互相通信，在不限制的前提下，Pod可以访问任意网络。
Pod拥有独立的网络栈，Pod看到自己的地址和外部看见的地址应该是一样的，并且同个Pod内所有的容器共享同个网络栈。
Kubernetes为了更好的控制网络的接入，推出了CNI即容器网络的API接口。它是Kubernetes中标准的一个调用网络实现的接口，kubelet通过这个API来调用不同的网络插件以实现不同的网络配置，实现了这个接口的就是CNI插件，它实现了一系列的CNI API接口。目前已经有的包括Flannel、Calico、Weave、Contiv等等。

实际上CNI的容器网络通信流程跟前面的基础网络一样，只是CNI维护了一个单独的网桥来代替 docker0。这个网桥的名字就叫作：CNI 网桥，它在宿主机上的设备名称默认是：cni0。cni的设计思想，就是：Kubernetes在启动Infra容器之后，就可以直接调用CNI网络插件，为这个Infra容器的Network Namespace，配置符合预期的网络栈。