zoukankan      html  css  js  c++  java
  • 1.Kubernetes基础架构&&概念

    Kubernetes基础架构&&概念

    集群架构与组件

    Master节点

    Master是集群的网关和中枢枢纽,主要作用:暴露API接口,跟踪其他服务器的健康状态、以最优方式调度负载,以及编排其他组件之间的通信。单个的Master节点可以完成所有的功能,但是考虑单点故障的痛点,生产环境中通常要部署多个Master节点,组成Cluster。

    master 概述
    APIServer Kubernetes API,集群的统一入口,各组件协调者,以RESTful API提供接口服务,所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给Etcd存储。
    Scheduler 根据调度算法为新创建的Pod选择一个Node节点,可以任意部署,可以部署在同一个节点上,也可以部署在不同的节点上。
    Controller-Manager 处理集群中常规后台任务,一个资源对应一个控制器,而ControllerManager就是负责管理这些控制器的。

    Work Node节点

    是Kubernetes的工作节点,负责接收来自Master的工作指令,并根据指令相应地创建和销毁Pod对象,以及调整网络规则进行合理路由和流量转发。生产环境中,Node节点可以有N个。

    Node 概述
    kubelet kubelet是Master在Node节点上的Agent,管理本机运行容器的生命周期,比如创建容器、Pod挂载数据卷、下载secret、获取容器和节点状态等工作。kubelet将每个Pod转换成一组容器。
    Pod(Docker or rocket) 容器引擎,运行容器。
    kube-proxy 在Node节点上实现Pod网络代理,维护网络规则和四层负载均衡工作。

    etcd数据存储

    分布式键值存储系统。用于保存集群状态数据,比如Pod、Service、网络等对象信息。

    核心附件

    K8S集群还依赖一组附件组件,通常是由第三方提供的特定应用程序

    核心插件 概述
    KubeDNS 在K8S集群中调度并运行提供DNS服务的Pod,同一集群内的其他Pod可以使用该DNS服务来解决主机名。K8S自1.11版本开始默认使用CoreDNS项目来为集群提供服务注册和服务发现的动态名称解析服务。
    Dashboard K8S集群的全部功能都要基于Web的UI,来管理集群中的应用和集群自身。
    Heapster 容器和节点的性能监控与分析系统,它收集并解析多种指标数据,如资源利用率、生命周期时间,在最新的版本当中,其主要功能逐渐由Prometheus结合其他的组件进行代替。从 v1.8 开始,资源使用情况的监控可以通过 Metrics API的形式获取,具体的组件为Metrics Server,用来替换之前的heapster,该组件1.11开始逐渐被废弃。
    Metric-Server Metrics-Server是集群核心监控数据的聚合器,从 Kubernetes1.8 开始,它作为一个 Deployment对象默认部署在由kube-up.sh脚本创建的集群中,如果是其他部署方式需要单独安装。
    Ingress Controller Ingress是在应用层实现的HTTP(S)的负载均衡。不过,Ingress资源自身并不能进行流量的穿透,它仅仅是一组路由规则的集合,这些规则需要通过Ingress控制器(Ingress Controller)发挥作用。目前该功能项目大概有:Nginx-ingress、Traefik、Envoy和HAproxy等。

    网络插件

    网络查件 概述
    Container Network Interface (CNI) 容器网络接口
    flunnal 实现网络配置,overlay network叠加网络
    calico 网络配置,网络策略;BGp协议,隧道协议
    canal(calico + flunnal) 供网络策略,配合flannel使用。

    Kubernetes基本概念

    基本概念
    Label资源标签 标签(key/value),附加到某个资源上,用于关联对象、查询和筛选;
    Labe Selector标签选择器 根据Label进行过滤符合条件的资源对象的一种机制
    Pod资源对象 Pod资源对象是一种集合了一个或多个应用容器、存储资源、专用ip、以及支撑运行的其他选项的逻辑组件
    Pod控制器(Controller) 管理Pod生命周期的资源抽象,并且它是一类对象,并非单个的资源对象,其中常见的包括:ReplicaSet、Deployment、StatefulSet、DaemonSet、Job&Cronjob等等
    Service服务资源 Service是建立在一组Pod对象之上的资源对象,通常用作防止Pod失联、定义一组Pod的访问策略,代理Pod
    Ingress 如果需要将某些Pod对象提供给外部用户访问,则需要给这些Pod对象打开一个端口进行引入外部流量,除了Service以外,Ingress也是实现提供外部访问的一种方式。
    Volume存储卷 保证数据的持久化存储
    Name&&Namespace Name是K8S集群中资源对象的标识符,通常作用于Namespace(名称空间),因此名称空间是名称的额外的限定机制。在同一个名称空间中,同一类型资源对象的名称必须具有唯一性。
    Annotation注解 另一种附加在对象上的一种键值类型的数据;方便工具或用户阅读及查找。

    Label 资源标签

    资源标签具体化的就是一个键值型(key/values)数据;使用标签是为了对指定对象进行辨识,比如Pod对象。标签可以在对象创建时进行附加,也可以创建后进行添加或修改。值得注意的是一个对象可以有多个标签,一个标签页可以附加到多个对象

    Labe Selector标签选择器

    有标签,当然就有标签选择器;例如将含有标签role: backend的所有Pod对象挑选出来归并为一组。通常在使用过程中,会通过标签对资源对象进行分类,然后再通过标签选择器进行筛选,最常见的应用就是为一组同样标签的Pod资源对象创建某个Service的端点。

    Pod资源对象

    Pod是kubernetes的最小调度单元;是一组容器的集合

    Pod可以封装一个活多个容器!同一个Pod中共享网络名称空间和存储资源,而容器之间可以通过本地回环接口:lo 直接通信,但是彼此之间又在Mount、User和Pid等名称空间上保持了隔离。

    Pod其实就是一个应用程序运行的单一实例,它通常由共享资源且关系紧密的一个或2多个应用容器组成。

    我们将每一个Pod对象类比为一个物理主机,那么运行在同一个Pod对象中的多个进程,也就类似于物理主机上的独立进程,而不同的是Pod对象中的各个进程都运行在彼此隔离的容器当中,而各个容器之间共享两种关键性资源;

    网络&&存储卷。

    • 网络:每一个Pod对象都会分配到一个Pod IP地址,同一个Pod内部的所有容器共享Pod对象的Network和UTS名称空间,其中包括主机名、IP地址和端口等。因此,这些容器可以通过本地的回环接口lo进行通信,而在Pod之外的其他组件的通信,则需要使用Service资源对象的Cluster IP+端口完成。
    • 存储卷:用户可以给Pod对象配置一组存储卷资源,这些资源可以共享给同一个Pod中的所有容器使用,从而完成容器间的数据共享。存储卷还可以确保在容器终止后被重启,或者是被删除后也能确保数据的持久化存储。

    一个Pod代表着一个应用程序的实例,现在我们需要去扩展这个应用程序;那么就意味着需要创建多个Pod实例,每个实例都代表着应用程序的一个运行副本。

    而管理这些副本化的Pod对象的工具,都是由一组称为Controller的对象实现;例如Deployment控制器对象。

    当创建Pod时,我们还可以使用Pod Preset对象为Pod注入特定的信息,比如Configmap、Secret、存储卷、卷挂载、环境变量等。有了Pod Preset对象,Pod模板的创建就不需要为每个模板显示提供所有信息。

    基于预定的期望状态和每个Node节点的资源可用性;Master会把Pod对象调度至选定的工作节点上运行,工作节点从指向的镜像仓库进行下载镜像,并在本地的容器运行时环境中启动容器。Master会将整个集群的状态保存在etcd中,并通过API Server共享给集群的各个组件和客户端

    Pod控制器(Controller)

    在介绍Pod时我们提到,Pod是K8S的最小调度单位;但是Kubernetes并不会直接地部署和管理Pod对象,而是要借助于另外一个抽象资源——Controller进行管理。

    常见的Pod控制器:

    Pod Controller
    Replication Controller 使用副本控制器,早起仅支持此Pod控制器;完成Pod增减、总数控制、滚动更新、回滚等操作,已停止使用
    ReplicaSet Controller 版本更新后使用副本集控制器,并对使用方法进行声明;是Replication Controller的升级版
    Deployment 用于无状态应用部署,例如nginx等;后续我们会提到HPA Controller(Horizontal Pod Autosaler):用于水平Pod自动伸缩控制器,对rs&deployment进行控制
    StatefulSet 用于有状态应用部署,例如mysql,zookeeper等
    DaemonSet 确保所有Node运行同一个Pod,例如网络查件flannel,zabbix_agent等
    Job 一次性任务
    Cronjob 定时任务

    控制器是更高级层次对象,用于部署和管理Pod。

    以Deployment为例,它负责确保定义的Pod对象的副本数量符合预期的设置,这样用户只需要声明应用的期望状态,控制器就会自动地对其进行管理。

    用户通过手工创建或者通过Controller直接创建的Pod对象会被调度器(Scheduler)调度到集群中的某个工作节点上运行,等到容器应用进程运行结束之后正常终止,随后就会被删除。

    当节点的资源耗尽或者故障,也会导致Pod对象的回收。

    在K8S的集群设计中,Pod是一个有生命周期的对象。那么使用了控制器实现对一次性的Pod对象进行管理操作。

    例如,要确保部署的应用程序的Pod副本数达到用户预期的数目,以及基于Pod模板来重建Pod对象等,从而实现Pod对象的扩容、缩容、滚动更新和自愈能力。

    例如,在某个节点故障,相关的控制器会将运行在该节点上的Pod对象重新调度到其他节点上进行重建。

    控制器本身也是一种资源类型,它们都统称为Pod控制器。如下图的Deployment就是这类控制器的代表实现,是目前用于管理无状态应用的Pod控制器。

    Pod Controller的定义通常由期望的副本数量、Pod模板、标签选择器组成。Pod Controller会根据Labe Selector来对Pod对象的标签进行匹配筛选,所有满足选择条件的Pod都会被当前Controller进行管理并计入副本总数,确保数目能够达到预期的状态副本数。

    在实际的应用场景中,在接收到的请求流量负载低于或接近当前已有Pod副本的承载能力时,需要我们手动修改Pod控制器中的期望副本数量以实现应用规模的扩容和缩容。而在集群中部署了HeapSet或者Prometheus的这一类资源监控组件时,用户还可以通过HPA(HorizontalPodAutoscaler)来计算出合适的Pod副本数量,并自动地修改Pod控制器中期望的副本数,从而实现应用规模的动态伸缩,提高集群资源的利用率。

    K8S集群中的每个节点上都运行着cAdvisor,用于收集容器和节点的CPU、内存以及磁盘资源的利用率直播数据,这些统计数据由Metrics聚合之后可以通过API server访问。而HorizontalPodAutoscaler基于这些统计数据监控容器的健康状态并作出扩展决策。

    Service服务资源

    主要作用or功能
    防止Pod失联 Service是建立在一组Pod对象之上的资源对象,在前面提过,它是通过Labe Selector选择一组Pod对象,并为这组Pod对象定义一个统一的固定访问入口(通常是一个IP地址),如果K8S存在DNS附件(如coredns)它就会在Service创建时为它自动配置一个DNS名称,用于客户端进行服务发现。
    定义一组Pod的访问策略,代理Pod 通常我们直接请求Service IP,该请求就会被负载均衡到后端的端点,即各个Pod对象,即负载均衡器;因此Service本质上是一个4层的代理服务,另外Service还可以将集群外部流量引入至集群,这就需要节点对Service的端口进行映射了。

    Pod对象有Pod IP地址,但是该地址在对象重启或者重建之后随之改变,Pod IP地址的随机性给应用系统依赖关系维护创造了不小的麻烦。

    例如:前端Pod应用Nginx无法基于固定的IP地址负载后端的Pod应用Tomcat

    Service资源就是在被访问的Pod对象中添加一个有着固定IP地址的中间层,客户端向该地址发起访问请求后,由相关的Service资源进行调度并代理到后端的Pod对象。

    Service并不是一个具体的组件,而是一个通过规则定义出由多个Pod对象组成而成的逻辑集合,并附带着访问这组Pod对象的策略。Service对象挑选和关联Pod对象的方式和Pod控制器是一样的,都是通过标签选择器进行定义。


    Service IP是一种虚拟IP,也称为Cluster IP,专用于集群内通信

    通常使用专有的地址段,如:10.96.0.0/12网络,各Service对象的IP地址在该范围内由系统动态分配。

    集群内的Pod对象可直接请求这类Cluster IP,比如上图中来自Pod client的访问请求,可以通过Service的Cluster IP作为目标地址进行访问,但是在集群网络中是属于私有的网络地址,只能在集群内部访问

    通常我们需要的是外部的访问;将引入集群内部的常用方法是通过节点网络进行,其实现方法如下:

    • 通过工作节点的IP地址+端口(Node Port)接入请求。
    • 将该请求代理到相应的Service对象的Cluster IP的服务端口上,通俗地说:就是工作节点上的端口映射了Service的端口。
    • 由Service对象将该请求转发到后端的Pod对象的Pod IP和 应用程序的监听端口。

    因此,类似于上图来自External Client的集群外部客户端,是无法直接请求该Service的Cluster IP,而是需要实现经过某一工作节点Node的IP地址,此时请求需要2次转发才能到目标Pod对象。这一类访问的缺点就是在通信效率上有一定的延时。

    Ingress

    K8S将Pod对象和外部的网络环境进行了隔离,Pod和Service等对象之间的通信需要通过内部的专用地址进行

    例如果需要将某些Pod对象提供给外部用户访问,则需要给这些Pod对象打开一个端口进行引入外部流量,除了Service以外,Ingress也是实现提供外部访问的一种方式。

    Volume存储卷

    存储卷(Volume)是独立于容器文件系统之外的存储空间,常用于扩展容器的存储空间并为其提供持久存储能力。

    存储卷在K8S中的分类为:

    1. 临时卷
    2. 本地卷
    3. 网络卷

    临时卷和本地卷都位于Node本地,一旦Pod被调度至其他Node节点,此类型的存储卷将无法被访问,因为临时卷和本地卷通常用于数据缓存,持久化的数据通常放置于持久卷(persistent volume)之中。

    Name和Namespace

    名称空间通常用于实现租户或项目的资源隔离,从而形成逻辑分组。关于此概念可以参考Docker文档中的概念https://www.jb51.net/article/136411.htm

    如图:创建的Pod和Service等资源对象都属于名称空间级别,未指定时,都属于默认的名称空间default

    Annotation注解

    Annotation是另一种附加在对象上的一种键值类型的数据,常用于将各种非标识型元数据(metadata)附加到对象上,但它并不能用于标识和选择对象。其作用是方便工具或用户阅读及查找。

  • 相关阅读:
    UVa 1151 Buy or Build【最小生成树】
    UVa 216 Getting in Line【枚举排列】
    UVa 729 The Hamming Distance Problem【枚举排列】
    HDU 5214 Movie【贪心】
    HDU 5223 GCD
    POJ 1144 Network【割顶】
    UVa 11025 The broken pedometer【枚举子集】
    HDU 2515 Yanghee 的算术【找规律】
    Java基本语法
    Java环境变量,jdk和jre的区别,面向对象语言编程
  • 原文地址:https://www.cnblogs.com/Gmiaomiao/p/12943744.html
Copyright © 2011-2022 走看看