【云原生之k8s】k8s基础详解

前言

Kubernetes的缩写为:K8S,这个缩写是因为k和s之间有八个字符的关系。
Kubernetes是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。Kubernetes拥有一个庞大且快速增长的生态系统。Kubernetesd的服务、支持和工具广泛可用。

一、kubernetes介绍

(1)kubernetes简介

kubernetes,是一个全新的基于容器技术的分布式架构领先方案,是谷歌严格保密十几年的秘密武器----Borg系统的一个开源版本,于2014年9月发布第一个版本,2015年7月发布第一个正式版本。

kubernetes的本质是一组服务器集群,它可以在集群的每个节点上运行特定的程序,来对节点中的容器进行管理。目的是实现资源管理的自动化,主要提供了如下的主要功能

  • 自我修复:一旦某一个容器崩溃,能够在1秒中左右迅速启动新的容器
  • 弹性伸缩:可以根据需要,自动对集群中正在运行的容器数量进行调整
  • 服务发现:服务可以通过自动发现的形式找到它所依赖的服务
  • 负载均衡:如果一个服务起动了多个容器,能够自动实现请求的负载均衡
  • 版本回退:如果发现新发布的程序版本有问题,可以立即回退到原来的版本
  • 存储编排:可以根据容器自身的需求自动创建存储卷

(2)应用部署方式的演变

在部署应用程序的方式上,主要经历了三个时代:

  • 传统部署:互联网早期,会直接将应用程序部署在物理机上
    优点:简单,不需要其它技术的参与
    缺点:不能为应用程序定义资源使用边界,很难合理地分配计算资源,而且程序之间容易产生影响
  • 虚拟化部署:可以在一台物理机上运行多个虚拟机,每个虚拟机都是独立的一个环境
    优点:程序环境不会相互产生影响,提供了一定程度的安全性
    缺点:增加了操作系统,浪费了部分资源
  • 容器化部署:与虚拟化类似,但是共享了操作系统
    优点:
    可以保证每个容器拥有自己的文件系统、CPU、内存、进程空间等
    运行应用程序所需要的资源都被容器包装,并和底层基础架构解耦
    容器化的应用程序可以跨云服务商、跨Linux操作系统发行版进行部署

在这里插入图片描述

容器化部署方式给带来很多的便利,但是也会出现一些问题,比如说:

  • 一个容器故障停机了,怎么样让另外一个容器立刻启动去替补停机的容器
  • 当并发访问量变大的时候,怎么样做到横向扩展容器数量
    常间容器编排软件
    这些容器管理的问题统称为容器编排问题,为了解决这些容器编排问题,就产生了一些容器编排的软件:
  • Swarm:Docker自己的容器编排工具
  • Mesos:Apache的一个资源统一管控的工具,需要和Marathon结合使用
  • Kubernetes:Google开源的的容器编排工具

二、kubernetes组件

(1)kubernetes架构

K8S 是属于主从设备模型(Master-Slave 架构),主节点一般被称为== Master 节点==,负责集群的调度、管理和运维。而从节点则被称为 Worker Node 节点,每个 Node 都会被 Master 分配一些工作负载。

在这里插入图片描述
Kubernetes主要由以下几个核心组件组成:
一个kubernetes集群主要是由控制节点(master)、工作节点(node)构成,每个节点上都会安装不同的组件。

  1. Master:集群的控制平面,负责集群的决策 ( 管理 )
  • etcd:负责存储集群中各种资源对象的信息
  • apiserver:提供了资源操作的唯一入口,接收用户输入的命令,并提供认证、授权、访问控制、API注册和发现等机制;
  • controller manager:负责维护集群的状态,比如故障检测、自动扩展、滚动更新等;
  • scheduler:负责资源的调度,按照预定的调度策略将Pod调度到相应的node节点上;
  1. node:集群的数据平面,负责为容器提供运行环境 ( 工作 )
  • kubelet:负责维护容器的生命周期,即通过控制docker,来创建、更新、销毁容器,同时也负责Volume(CVI)和网络(CNI)的管理;
  • Container runtime:负责镜像管理以及Pod和容器的真正运行(CRI);
  • kube-proxy:负责为Service提供cluster内部的服务发现和负载均衡;
  • pod:kubernetes的最小控制单元,容器都是运行在pod中的,一个pod中可以有1个或者多个容器

(2)master组件

集群的控制平面,负责集群的决策 ( 管理 )

扫描二维码关注公众号,回复: 14442279 查看本文章

①apiserver

Kubernetes API,集群的统一入口,各组件协调者,以**Restful API提供接口服务,所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给Etcd存储。

用于暴露Kubernetes API,任何资源请求或调用操作都是通过kube-apiserver 提供的接口进行。以HTTP Restful API提供接口服务,所有对象资源的增删改查和监听操作都交给API Server 处理后再提交给Etcd 存储(相当于分布式数据库,以键值对方式存储)。
可以理解成API Server 是K8S的请求入口服务。API server负责接收K8S所有请求(来自UI界面或者CLI 命令行工具),然后根据用户的具体请求,去通知其他组件干活。可以说API server 是K8S集群架构的大脑。

②controller-manager控制管理中心

运行管理控制器,是k8s集群中处理常规任务的后台线程,是k8s集群里所有资源对象的自动化控制中心。
在k8s集群中,一个资源对应一个控制器,而Controller manager 就是负责管理这些控制器的。
由一系列控制器组成,通过API Server监控整个集群的状态,并确保集群处于预期的工作状态,比如当某个Node意外宕机时,Controller Manager会及时发现并执行自动化修复流程,确保集群始终处于预期的工作状态.

控制器 功能
Node Contrpller(节点控制器) 负责在节点出现故障时发现和响应
Replication Controller ( 副本控制器) 负责保证集群中一个RC (资源对象ReplicationController)
Endpoints Controller (端点控制器) 填充端点对象(即连接Services 和Pods) ,负责监听Service 和对应的Pod 副本的变化。可以理解端点是一个服务暴露出来的访问点,如果需要访问一个服务,则必须知道它的 endpoint
Service Account & Token Controllers (服务帐户和令牌控制器) 为新的命名空间创建默认帐户和API访问令牌
Resource Quota Controller(资源配额控制器) 确保指定的资源对象在任何时候都不会超量占用系统物理资源
Namespace Controller (命名空间控制器) 管理namespace的生命周期
Service Controller (服务控制器) 属于K8S集群与外部的云平台之间的一个接口控制器

③scheduler

  • 根据调度算法预选/优选的策略)为新创建的Pod选择一个Node节点,可以任意部署,可以部署在同一个节点上,也可以部署在不同的节点上
  • 可以理解成K8S所有Node 节点的调度器。当用户要部署服务时,scheduler 会根据调度算法选择最合适的Node 节点来部署Pod
  • API Server 接收到请求创建一批Pod,API Server 会让Controller-manager 按照所预设的模板去创建Pod,Controller-manager 会通过API Server去找Scheduler为新创建的Pod选择最适合的Node 节点。比如运行这个Pod需要2C4G 的资源,Scheduler会通过预算策略在所有Node节点中挑选最优的。Node 节点中还剩多少资源是通过汇报给API Server 存储在etcd 里,API Server 会调用一个方法找到etcd 里所有Node节点的剩余资源,再对比Pod 所需要的资源,在所有Node 节点中查找哪些Node节点符合要求。
  • 如果都符合,预算策略就交给优选策略处理,优选策略再通过CPU的负载、内存的剩余量等因素选择最合适的Node 节点,并把Pod调度到这个Node节点上运行。
  • controller manager会通过API Server通知kubelet去创建pod,然后通过kube-proxy中的service对外提供服务接口。(node组件)

④etcd(存储中心)

  • 分布式键值存储系统(特性:服务自动发现)。用于保存集群状态数据,比如Pod、Service等对象信息

  • k8s中仅API Server 才具备读写权限,其他组件必须通过API Server 的接口才能读写数据

    PS:etcd V2版本:数据保存在内存中
    v3版本:引入本地volume卷的持久化(可根据磁盘进行恢复),服务发现,分布式(方便扩容,缩容)
    etcd是一种定时全量备份+持续增量备份的持久化方式,最后存储在磁盘中
    但kubernetes 1.11版本前不支持v3,我用的事K8S 1.15
    ETCD一般会做为3副本机制(奇数方式),分布在三台master上(也有的公司单独用服务器部署ETCD )
    master:奇数的方式部署(多节点的时候)
    

(3)node组件

①kubelet

  • kubelet是Master在Node节点上的Agent,管理本机运行容器的生命周期,比如创建容器、Pod挂载数据卷、下载secret、获取容器和节点状态等工作。kubelet将每个Pod转换成一组容器

kubelet —》先和docker引擎进行交互—》docker容器(一组容器跑在Pod中)

②kube-proxy

在Node节点上实现Pod网络代理,维护网络规则、pod之间通信和四层负载均衡工作。默认会写入规则至iptables ,目前支持IPVS、同时还支持namespaces

对于七层的负载,k8s官方提供了一种解决方案;ingress-nginx

③pod

Pod是Kubernetes 创建或部署的最小/最简单的基本单位,一个Pod代表集群上正在运行的一个进程。
一个Pod 由一个或多个容器组成,Pod 中容器共享网络、存储和计算资源,在同一台Docker 主机上运行。
一个Pod里可以运行多个容器,又叫边车模式(SideCara) 模式。而在生产环境中一 般都是单个容器或者具有强关联互补的多个容器组成一 个Pod。
同一个Pod 之间的容器可以通过localhost 互相访问,并且可以挂载Pod 内所有的数据卷;但是不同的Pod之间的容器不能用localhost访问,也不能挂载其他Pod的数据卷。

pod控制器
Pod控制器是Pod启动的一种模版,用来保证在K8S里启动的Pod应始终按照用户的预期运行(副本数、生命周期、健康状态检查等)
K8s内提供了众多的Pod控制器,常用的有以下几种:
(1)Deployment:无状态应用部署。Deployment 的作用是管理和控制Pod和ReplicaSet, 管控它们运行在用户期望的状态中。
(2)Replicaset: 确保预期的Pod 副本数量。Replicaset 的作用就是管理和控制Pod, 管控他们好好干活。但是,ReplicaSet 受控于Deployment。
可以理解成Deployment 就是总包工头,主要负责监督底下的工人Pod 干活,确保每时每刻有用户要求数量的Pod在工作。如果一旦发现某个工人Pod 不行了,就赶紧新拉一个Pod 过来替换它。而ReplicaSet 就是总包工头手下的小包工头。
从K8S使用者角度来看,用户会直接操作Deployment 部署服务,而当Deployment 被部署的时候,K8S 会自动生成要求的ReplicaSet和Pod。用户只需要关心Deployment 而不操心ReplicaSet。
资源对象Replication Controller 是ReplicaSet 的前身,官方推荐用Deployment 取代Replication Controller 来部署服务。
(3)Daemonset: 确保所有节点运行同一类Pod,保证每 个节点上都有一个此类Pod运行,通常用于实现系统级后台任务。
(4)Statefulset: 有状态应用部署
(5)Job:一次性任务。 根据用户的设置,Job管理的Pod把任务成功完成就自动退出了。
(6)Cronjob: 周期性计划性任务

(4)工作流程

  1. 首先运维人员使用kubectl命令行工具向API Server发送请求,API Server接收到请求后会写入到etcd中,API Server会让Controller-manager按照预设的模板去创建pod,Controller-manager通过 API Server读取etcd中用户的预设信息,再通过API Server去找 Scheduler可以为新创建的pod选择最适合的node节点。scheduler会通过API Server在Etcd存储中心根据存储的node节点元信息、剩余资源等,用预选策略和优选策略挑选最优的node节点
  2. scheduler确定node节点后通过API Server交给这个Node节点上的kubelet进行pod资源的创建,kubelet调用容器引擎交互创建pod,同时将pod监控信息通过API server存储到etcd中
  3. 用户访问时,通过kube-proxy负载、转发,访问相应的pod

(5)Pod创建流程

kubectl 创建一个Pod(在提交时,转化为json格式
1、首先经过auth认证(鉴权),然后传递给api-server进行处理
2、api-server 将请求信息提交给etcd
3、scheduler和controller-manager 会watch(监听) api-server ,监听请求
4、在scheduler 和controller-manager监听到请求后,scheduler 会提交给api-server一个list清单——>>包含的是获取node节点信息
5、此时api-server就会向etcd获取后端node节点信息,获取到后,被scheduler watch到,然后进行预选优选进行打分,最后将结果给与api-server
6、此时api-server也会被controller-manager watch(监听) controller-manager会根据请求创建Pod的配置信息(需求什么控制器)将控制器资源给与api-server
7、此时api-server 会提交list清单给与对应节点的kubelet(代理)
8、kubelet代理通过K8S与容器的接口(例如containerd)进行交互,假设是docker容器,那么此时kubelet就会通过dockershim 以及runc接口与docker的守护进程docker-server进行交互,来创建对应的容器,再生成对应的Pod
9、kubelet 同时会借助于metrics server 收集本节点的所有状态信息,然后再提交给api-server
10、最后api-server会提交list清单给与etcd来存储(最后api-server会将数据维护在etcd中)

三、Kubernetes核心概念

Kubernetes包含多种类型的资源对象: Pod、 Label、 Service、 Replication Controller 等。
所有的资源对象都可以通过Kubernetes 提供的kubectl 工具进行增、删、改、查等操作,并将其保存在etcd 中持久化存储。
Kubernets其实是一个高度自动化的资源控制系统,通过跟踪对比etcd存储里保存的资源期望状态与当前环境中的实际资源状态的差异,来实现自动控制和自动纠错等高级功能。

(1)Service

在K8s的集群里,虽然每个Pod会被分配一个单独的IP地址,Pod是有生命周期的。当一个工作节点(Node)销毁时,节点上运行的Pod也会销毁,然后通过ReplicationController动态创建新的Pods来保持应用的运行。Service就是用来解决这个问题的核心概念。

Kubernetes中的Service 是一个抽象的概念,它定义了Pod的逻辑分组和一种可以访问它们的策略,这组Pod能被Service访问,使用YAML (优先)或JSON 来定义Service,Service所针对的一组Pod通常由LabelSelector实现。

Service 是== K8S服务的核心,屏蔽了服务细节,统一对外暴露服务接口==

Service的四种type:

  • ClusterIP(默认) - 在集群中内部IP上暴露服务。此类型使Service只能从群集中访问。
  • NodePort - 通过每个 Node 上的 IP 和静态端口(NodePort)暴露服务。NodePort 服务会路由到ClusterIP 服务,这个 ClusterIP 服务会自动创建。通过请求 :,可以从集群的外部访问一个 NodePort 服务。
  • LoadBalancer - 使用云提供商的负载均衡器(如果支持),可以向外部暴露服务。外部的负载均衡器可以路由到 NodePort 服务和 ClusterIP 服务。
  • ExternalName - 通过返回 CNAME 和它的值,可以将服务映射到 externalName 字段的内容,没有任何类型代理被创建。这种类型需要v1.7版本或更高版本kube-dnsc才支持。

小结:

在K8S集群中,service 可以看作一组提供相同服务的Pod的对外访问接口。
客户端需要访问的服务就是service对象。每个service都有一个固定的虛拟ip 
(这个ip也被称为Cluster IP) ,自动并且动态地绑定后端的Pod, 
所有的网络请求直接访问Service 的虚拟ip,service会自动向后端做转发。
Service除了提供稳定的对外访问方式之外,还能起到负载均衡(Load Balance)
的功能,自动把请求流量分布到后端所有的服务.上,Service可以做到对客户
透明地进行水平扩展(scale)。
而实现service 这一功能的关键, 就是kube-proxy。 
kube-proxy 运行在每个节点上,监听API Server 中服务对象的变化,
可通过以下三种流量调度模式:

userspace (废弃)、
iptables ( 濒临废弃)、
ipvs (推荐,性能最好)来实现网络的转发。

Kubernetes Service 是一个抽象层,统一对外暴露服务接口,应用可以方便的实现服务发现与负载均衡。

(2)Label标签

  • 标签,是K8S特色的管理方式,便于分类管理资源对象。

  • Label可以附加到各种资源对象.上,例如Node、Pod、Service、 RC等,用于关联对象、查询和筛选。

  • 一个Label 是一个key-value 的键值对,其中key 与value 由用户自己指定。

  • 一个资源对象可以定义任意数量的Label,同一个Label也可以被添加到任意数量的资源对象中,也可以在对象创建后动态添加或者删除。

  • 可以通过给指定的资源对象捆绑一个或多个不同的Label,来实现多维度的资源分组管理功能。

  • 与Label 类似的,还有Annotation (注释)

  • 区别在于有效的标签值必须为63个字符或更少,并且必须为空或以字母数字字符( [a-z0-9A-Z])开头和结尾,中间可以包含横杠(-)、下划线(_)、点(.)和字母或数字。注释值则没有字符长度限制。
    Label选择器(Label selector )

  • 给某个资源对象定义一个Label,就相当于给它打了一个标签;随后可以通过标签选择器( Label selector) 查询和筛选拥有某些Label的资源对象。

  • 标签选择器目前有两种:基于等值关系(等于、不等于)和基于集合关系(属于、不属于、存在)。

ps:如下图,相同的label处于同一service

在这里插入图片描述

(3)Ingress七层负载

Service主要负责K8S集群内部的网络拓扑,那么集群外部怎么访问集群内部呢?这个时候就需要Ingress 了。Ingress 是整个K8S集群的接入层,负责集群内外通讯。

Ingress是K8S 集群里工作在OSI网络参考模型下,第7层的应用,对外暴露的接口,典型的访问方式是http/https.

Service只能进行第四层的流量调度,表现形式是iptport。 Ingress 则可以调度不同业务域、不同URL访问路径的业务流量。

比如:客户端请求http://www. kgc。com:port —> Ingress —> Service —> Pod

(4)Name

  • 由于K8S内部,使用“资源”来定义每一种逻辑概念(功能),所以每种“资源”,都应该有自己的“名称”。
  • “资源”有api 版本(apiversion) 、类别(kind) 、元数据(metadata) 、定义清单(spec) 、状态(status) 等配置信息。
  • “名称”通常定义在“资源”的“元数据”信息里。在同一个namespace 空间中必须是唯一的。

(5)Namespace

随着项目增多、人员增加、集群规模的扩大,需要一种能够逻辑上隔离K8S内各种“资源”的方法,这就是Namespace 。

Namespace是为了把一个K8S集群划分为若干个资源不可共享的虚拟集群组而诞生的。

不同Namespace 内的“资源”名称可以相同,相同Namespace 内的同种“资源”,“名称”不能相同。

合理的使用K8S的Namespace,可以使得集群管理员能够更好的对交付到K8S里的服务进行分类管理和浏览。

K8S里默认存在的Namespace 有: default、kube-system、kube-public等。
查询K8S里特定“资源”要带上相应的Namespace

猜你喜欢

转载自blog.csdn.net/qq1356059950/article/details/126147630
k8s
今日推荐