Kubernetes特性

  • 自动装箱
    kubernetes构建于容器之上,基于资源依赖及其它约束自动完成容器部署且不影响其可用性,同时,为了提高利用率和节省更多资源,将关键和最佳工作量结合在一起。
  • 自我修复
    支持容器故障后自动重启、节点故障后重新调度容器,以及其它可用节点,健康检测失败后关闭容器并重新创建灯自我修复机制。
  • 水平扩展
    支持通过简单命令或UI手动水平扩展,以及基于CPU等资源负载率的自动水平扩展机制。
  • 服务发现和负载均衡
    kubernetes通过附加组件之一的 KubeDNS/CoreDNS 为系统内置了服务发现功能,它会为每个Service配置DNS名称,并允许集群内的客户端直接使用此名称发出访问请求,而Service则通过iptables或ipvs内建了负载均衡机制。
  • 自动发布和回滚
    kubernetes支持 灰度 更新应用程序或配置信息,它会监控更新过程中应用程序的健康状态,以确保它不会在同一时间杀掉所有pods,而此过程中一旦有故障发生,就会立即自动执行回滚操作。
  • 密钥和配置管理
    kubernetes的Config Map实现了配置数据与Docker镜像解耦,需要时,仅对配置做出变更而无需重新构建Docker镜像,这为应用开发部署带来了很大的灵活性。刺猬,对于应用所依赖的一些敏感数据,如用户名和密码、令牌、密钥等信息,kubernetes专门提供了Secret对象为其解耦,即便利了应用快速开发和交付,又提供了一定程度上的安全保障。
  • 存储编排
    kubernetes 支持 pod 对象按需自动挂载不同类型的存储系统,这包括节点本地存储,网络存储,云存储等。
  • 批量处理执行
    除了服务器型应用,kubernetes还支持批处理作业及CI(持续集成),如果需要,一样可以实现容器故障后恢复。

Kubernetes概念和术语

Kubernetes使用共享网络将多个物理机和虚拟机汇集到一个集群中,在各服务器之间进行通信,该集群是配置Kubernetes的所有组件、功能和工作负载的物理平台。及群众一台服务器(或高可用部署中的一组服务器)用作 Master,负责管理整个集群,余下的其他机器用作 Node工作节点,他们是使用本地和外部资源接收和运行工作的负载服务器,如下图所示,集群中这些服务器可以使物理服务器,也可以是虚拟机。

概念讲解

  • 1.Master
    Master 是集群的网关和中心,负责注入为用户和客户端暴露 API、跟踪其他服务器的健康状态、以最优方式调度工作负载,以及编排其它组件之间的通信等任务,它是用户或客户端之间的核心联络点,并负责Kubernetes系统的大多数集中式管控逻辑。单个 Master节点即可完成所有功能,但是出于负载均衡及高可用目的,生产环境通常需要部署多个此类主机。
  • 2.Node
    Node 是 Kubernetes 集群的工作节点,负责接收来自 Master 的工作指令并根据指令相应地创建和销毁 Pod 对象,以及调整网络规则以合理地路由和转发流量等。理论上讲,Node可以使任何形式的计算设备,不过 Master 会统一将其抽象为 Node 对象进行管理。

Kubernetes 将所有Node的资源集结于一处形成一台更加强大的 “服务器”,如下图所示,在用户将应用部署到 Node 上时,Master使用调度算法 Scheduler将其自动指派至某个特定的 Node 运行,在 Node加入集群或从集群中移除时,Master也会按需重新编排影响到Pod(容器)。于是,我们无需关心应用到底在哪个Node上。

术语讲解

  • 1.Pod
    Kubernetes并不直接运行容器,而是使用一个抽象的资源对象来封装一个或多个容器,这个抽象就被称为 Pod,它也是 Kubernetes 的最小调度单元,在Kubernetes中,容器不称为我们之前在Docker中所谓的容器,而是被称为 Pod。同一个 Pod 中可以有多个容器并且同一个Pod中的多个容器共享网络名称和存储资源,这些容器可通过本地回环接口 lo 直接通信,但彼此之间又在 Mount、User、PID等名称空间上保持了隔离。尽管 Pod 中可以包含多个容器,但是作为最小调度单元,它应该尽可能的保持 “小”,所以通常一个Pod中只有一个主容器和其它辅助容器,辅助容器指的是(Filebeats、zabbix_agent客户端等)。
    我的理解为:“一个Node可以包含多个Pod,一个Pod可以包含多个容器,一个Node为一台主机(物理机/虚拟机/云主机。。。。),一个Pod基于Node之上,又可以在一个Pod中运行多个容器,但我们通常只运行一个主容器,其余为辅助容器”。
  • 2.Label/资源标签
    标签(Label)是将资源进行分类的标识符,表面意思可以与Docker中的tag一致,在Docker中我们给容器打标签tag,但是在Kubernetes中我们需要给 Pod 来打标签。资源标签是一个键值型 (Key/Values)格式的数据。添加标签的主要作用是为了增加辨识度,添加的标签对用户存在特定的意义。标签可以在 Pod 创建的时候指定,也可以在创建 Pod 后任意时间进行添加和修改。
    一个 Pod 可以拥有多个标签Lable,一个标签也可以属于多个 Pod。通常用法如下图所示。

  • 3.标签选择器
    标签选择器(Selector),全称为 ”Label Selector“,标签选择器通过 Label来过滤符合条件的 Pod,例如附有标签 ”application:nginx“的所有 Pod 挑选出来归纳为一类,并为归纳出的这组标签的 Pod 创建为 Service的端点。

  • 4.Pod控制器
    尽管 Pod 是 Kubernetes的最小调度单元,但用户通常不会直接部署及管理 Pod 对象,而是借助另外一类抽象,这类抽象被称为——》控制器(Controller)对其进行管理。用于工作负载的控制器是一种管理 Pod 生命周期的资源抽象,他们是 Kubernetes 上的一类对象,而非单个资源对象,,控制器包括以下
    ReplicationControllerReplicaSetDeploymentStatefulSetJob等。
    下图中以 Deployment控制器为例,我们在其中定义了 Pod 对象的副本数量(就是一个Pod的副本,可以作为高可用使用的副本)为3,就必须精确为3各 Pod,否则”多退少补“。使用控制器之后就不再需要手动管理Pod对象了,用户只需要声明应用的期望状态,控制器就会自动对其进行进程管理。

  • 5.服务资源(Service)
    Service 是建立在一组 Pod 对象之上的资源抽象,Kubernetes通过标签选择器 Label Selector选择后的一组 Pod 对象,并为这组 Pod对象定义一个统一且固定的访问入口(通常是一个IP地址),若Kubernetes集群存在 DNS附件,它就会在Service创建时为其自动配置一个DNS名称以便客户端进行服务发现。到达Service IP的请求将被负载均衡至其后的端点——各个Pod对象之上,因此 Service从本质上来讲是一个四层代理服务。另外Service还可以将集群外部流量引入到集群中来。
  • 6.存储卷
    存储卷(Volume)是独立于容器文件系统之外的存储空间,常用于扩展容器的存储空间并为容器提供持久存储能力。Kubernetes集群上的存储卷大体可以分为临时卷本地卷网络卷。临时卷和本地卷都位于 Node 本地,一旦 Pod 被调度至其他 Node,此种类型的存储卷将无法访问到,因此临时卷和本地卷常用语数据缓存,持久化的数据则需要放置于持久卷(presistent volume)之上。
  • 7.Name和NameSpace
    名称(Name)是Kubernetes集群中资源对象的标识符,他们的作用于通常是名称空间(NameSpace),因此名称空间是名称的额外限定机制。在用一个名称空间中(同一名称空间一般为:Node与Node之间名称,Service与Service之间名称,Pod与Pod之间名称,同一Pod下容器名称),同一类型资源对象的名称必须具备唯一性。名称空间常用于实现租户或项目的资源隔离,从而形成逻辑分组,如下图所示,创建的 Pod 和 Service 等资源对象都属于名称空间级别,未指定时,他们都属于默认名称空间 ”default“
    下图中的三个 Pod ,分为为:默认 Pod 名称空间公开 Pod 名称空间系统 Pod 名称空间

  • 8.Annotation
    Annotation(注解)是一种附加在 Pod 对象之上的键值类型数据,但它拥有更大的数据容量。Annotation 常用于将各种非标识型元数据(matedata)附加到对象上,但它不能用于标识和选择对象。常规之意即为 ”注释“
  • 9.Ingress
    Kubernetes将Pod对象和外部网络环境进行了隔离,Pod 和 Service等对象间的通信都使用其内部专用地址进行,加入需要开放某些 Pod 对象提供给外部用户访问,则需要为其请求流量打开一个通往 Kubernetes集群内部的通道,除了 Service 之外,Ingress也是这类通道的实现方式之一。Ingrss被称为入口。

Kubernetes系统组件

一个Kubernetes集群由多个工作节点(worker node)和一个或多个集群控制节点(Master)以及一个集群状态存储系(etcd)组成。

Master节点

Master主要负责整个集群的管理工作,为集群提供管理接口,并监控和编排集群中的各个工作节点。各节点负责以 Pod 形式运行Docker容器。
Master节点主要由 apiserver、scheduler、contrller-manager三个组件以及一个集群存储系统 etcd 组成。

  • API Server
    API Server 负责输出 RESTful 风格的 Kubernetes API,它是发往集群的所有 REST 操作命令的接入点,并负责接收、校验并响应所有的REST请求,结果状态被持久存储于 etcd 中,因此,API Server是整个集群的网关。
    API Server主要负责暴露Kubernetes API,不管是 kubectl 还是 UI 工具以及程序代码来操作 Kubernetes的各种资源,都是通过 API Server提供的
    接口进行操作的。
  • scheduler
    scheduler为调度器,Kubernetes可以用于部署大规模的容器应用平台,可能会同时托管成千上万台容器,APIServer确认Pod对象创建请求之后,便需要由Scheduler根据集群内各节点的可用资源状态和要运行容器的资源需求做出调度算法,然后将外部来的请求转发至某一后端pod。
  • controller-manager
    controller manageer被称为控制管理器。Kubernetes中,集群级别的大多数功能都是由几个被称为控制器的进程所实现的,这几个进程被集成于 kube-controller-manager守护进程中。由控制器完成的功能主要包括生命周期和API业务逻辑,具体如下。

    • 生命周期功能:包括 Namespace 创建和生命周期、Event 垃圾回收、Pod 终止相关的垃圾回收、级联垃圾回收及 Node 垃圾回收等。
    • API 业务逻辑:例如,由 RepliaSet 执行的 Pod 扩展等。
  • etcd
    etcd被称为集群状态存储(Cluster State Store),Kubernetes集群的所有状态信息都需要持久存储到etcd系统中,不过,etcd是由 CoreOS 基于 Raft 协议开发的分布式键值存储,可用于服务发现、共享配置以及一致性保障。因此,etcd是独立的服务组件,并不属于Kubernetes集群自身。生产环境中应用以 etd 集群的方式运行以确保其服务可用性。

etcd不仅能够提供键值数据存储,而且还为其提供了监听 (watch)机制,用于监听和推送变更。Kubernetes集群系统中,etcd中的键值发生变化时会通知到 API Server,并由其通过 watch API向客户端输出。基于watch机制,Kubernetes集群的各个组件实现了高效协同。

Node节点

Node节点主要负责提供运行容器的各种依赖环境,并接受 Master 管理。每个Node主要由 Kubelet、容器、kube-proxy三个组件组成。

  • kubelet
    kubelet时运行在Node节点之上的守护进程,它从API Server接收关于Pod对象的配置信息并确保他们处于期望状态(desired state)。kubelet 会在 API Server上注册当前工作节点,定期向 Master 汇报当前节点资源使用情况,并通过 cAdvisor 监控容器和节点的资源占用情况。
  • 容器引擎
    每个Node都需要提供一个容器运行环境,它负责下载镜像并运行容器,kubelet并未固定连接至某容器的运行环境,而是以插件的方式载入配置的容器环境,这种方式清晰的定义了各组件的边界。Kubernetes的容器环境并不只是为Docker所准备,其它的容器产品同样可以被Kubernetes所托管。如:Docker、RKT、cir-o和 Fraki等
  • kube-proxy
    每个Node节点都需要运行一个 kube-proxy 的守护进程,它能够按需为 Service 资源对象生成 iptables 或 ipvs 规则,从而捕获当前 Service的ClusterIP流量并将其转发至正确的后端 Pod 对象。

核心附件

Kubernetes集群还依赖于一组称为 “附件” 的组件以提供完整的功能,他们通常是由第三方提供的特定应用程序,且托管运行于 Kubernetes 集群之上,如上图中的 kube-system-namespace块中所示。

  • KubeDNS/CoreDNS:在Kubernetes集群中调度运行提供DNS服务的 Pod,同一集群中的其它 Pod 可使用此 DNS 服务解决主机名,Kubernetes自 1.11 版本开始默认使用CoreDNS项目为集群提供服务注册和服务发现的动态名称解析服务,之前的版本中用到的是 kube-dns 项目,而 SykDNS 则是更早一代的项目。
  • Dashhoard:Kubernetes 集群的全部功能都要基于 Web 的 UI 来管理集群中的应用甚至集群自身。
  • Heapster:容器和节点对的性能监控与分析系统,它手机并解析多种指标数据,如资源利用率、生命周期事件等。新版本的 Kubernetes 中,功能会慢慢由 Prometheus 结合其它组件所取代。
  • Ingress Controller:Service 是一种工作与传统的负载均衡器,而 Ingress 是在应用层实现的 HTTP/HTTPS负载均衡机制,不过 Ingress 资源自身并不能进行 “流量穿透”,它仅是一组路由规则的集合,这些规则需要通过 Ingress 控制器(Ingress Controller)发挥作用,目前,此类的可用项目用 Nginx、HAProxy、Traefik、Envoy等。

Kubernetes网络模型

云计算的核心是虚拟化技术,网络虚拟化技术又是最重要的组成部分,用于在物理网络上虚拟多个相互隔离的虚拟网络,实现网络资源切片,提高网络资源利用率,实现弹性化网络。Kubernetes作为容器云技术栈中的容器编排组件,必然需要在多租户(名称空间)的基础上实现弹性网络管理,这也是 ”基础设置“ 的要求之一。

网络模型概述

Kubernetes的网络主要存在四种类型的通信:
1)同一 Pod 内容器之间通信
2)各个 Pod 之间彼此通信
3)Pod 与 Service 之间的通信
4)集群外部流量与 Service之间的通信

Kubernetes为 Pod 和 Service 资源对象分别使用了各自的专用网络, Pod 网络由 Kubernetes的网络插件(常用的网络插件为 Flannel)指定。而 Service 的网络则由 Kubernetes 集群直接指定,为了提供更灵活的解决方式,Kubernetes的网络模型需要借助外部插件实现,它要求任何实现机制都必须满足以下需求。
1)所有 Pod 间都可以不经过 NAT 转换而直接通信
2)所有节点都可以不经过 NAT 转换而直接与所有容器通信。
3)容器自己使用的 IP 也是其它容器或节点可以直接看到的地址,所有 Pod 对象都位于同一网络平面/同一网络中,而且可以使用 Pod 自身的地址直接通信。

Kubernetes 使用的网络插件必须能为 Pod 提供满足以上要求的网络,它需要为每个 Pod 上配置至少一个特定地址,即 Pod IP,Pod IP实际存在某个网络(可以是虚拟设备)上,而 Service 的地址却是一个虚拟 IP 地址,不在任何网络接口上,它由 kube-proxy 借助 iptables 规则或 ipvs 规则重定向到本地端口,再将其调度至后端 Pod IP上。
Service 的 IP 地址是集群提供的接口,也被称为 Cluster IP

Pod 网络及 Pod IP由 Kubernetes 的网络插件Flannel来配置和管理,具体使用的网络地址可以在配置管理插件的时候指定,默认为 10.244.0.0/16 网络。而 Cluster/Service 网络和 IP 则是由 Kubernetes 集群负责配置和管理,默认为 10.96.0.0/12网络。

Kubernetes集群至少应该包含三个网络,如下图所示:
网络一:各个宿主机 MasterNodeetcd 之间的网络,用于宿主机之间的通信。

网络二:Kubernetes 集群上专用于 Pod 资源对象的网络,它是一个虚拟网络,用于为各个 Pod 对象设定Ip地址等网络参数,其地址配置于 Pod 中容器的网络接口之上。Pod 网络需要借助 kubenet 插件或 CNI (Container Network Interface:容器网络接口)实现,Flannel亦是基于CNI协议之上的网络插件,该插件可独立部署与 Kubernetes 集群之外,也可以以 Pod 的形式托管在 Kubernetes 之上,他需要在构建 Kubernetes 集群时由管理员进行定义,而后在穿件 Pod 对象时由其自动完成各网络参数的动态配置。

网络三:用于 Service 资源对象的网络,它属于一个虚拟网络,却不在任何网络接口上,用于为 Kubernetes 集群之中的 Service 配置 IP 地址,但此地址并不配置与任何主机或容器的接口之上,而是通过 Node 之上的 kube-proxy 配置为 iptables 或者 ipvs 规则,从而发往此地址的所有流量调度至其后端的各 Pod 对象之上。Service 网络/网段在 Kubernetes 集群创建时给予指定,而各 Service 的IP地址则在用户创建 Service时给予动态指定配置。

集群上的网络通信

Kubernetes 集群的客户端大概可以分为两类:API Server 客户端和应用程序(运行为 Pod 中的容器)客户端,如下图所示。
第一类客户端即是图中的 开发/运维 所通过 APIServer 使用 kubectl 或 Web 图形 UI (例如 Kubernetes Dashboard)进行对Kubernetes集群的管理任务,例如,管理集群上的各种资源对象。
第二类客户端即为图中的 应用客户端,他们访问的目标是 Pod 上运行于容器中的应用程序所提供的服务,如 Redis、Nginx等,不过这些访问请求要由 Server 或 Ingress资源对象转发给 Pod进行。

参考文献

参考书籍:Kubernetes进阶实战

本站文章基于国际协议BY-NA-SA 4.0协议共享;
如未特殊说明,本站文章皆为原创文章,请规范转载。

0

欢迎来到Kubernetes技术栈~~