您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 
 订阅
k8s入门教程详解
 
作者:宝山的博客
  52736  次浏览      22 次
 2022-4-18
 
编辑推荐:
这篇文章主要讲述 k8s入门教程详解 相关的知识,希望能为你提供帮助。
本文来自于CSDN,由Alice编辑、推荐。

Kubernetes 入门教程详解(一)

一、 Kubernetes 概述

1. K8S 发展历史由来

  • 它前生是 谷歌的Borg 系统,后经过Go 语言重写,在 2014 年开源了 Kubernetes 项目,并捐献给CNCF 基金会开源,即 Kubernetes。
  • 它之所以简称 ‘k8s',因为 Kubernetes 中间有 8个字母

2.K8S官网

  • kubernetes的github地址:
    • https://github.com/kubernetes/kubernetes
  • kubernetes官方站点:
    • 英文官方网址: https://kubernetes.io/
    • z中文官方网站: https://kubernetes.io/zh/
    • 英文官方文档: https://kubernetes.io/docs/

2.K8S 是什么

  • Kubernetes 是一个可移植的、可扩展的 开源平台 ,用于 管理容器化的工作负载和服务,可促进声明式配置和自动化 。 Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。
  • Kubernetes 这个名字源于希腊语,意为“舵手”或“飞行员”
  • 官网 :https://kubernetes.io/
  • GitHub :https://github.com/kubernetes/kubernetes
  • 具有 轻量级 、 消耗资源小 、 开源 、 弹性伸缩 、 负载均衡(IPVS) 的特点

3. K8s 优势及特点

3.1 K8S优势

  • 自动装箱,水平扩展,自我修复
  • 服务发现和负载均衡
  • 自动发布和回滚
  • 集中化配置管理和密钥管理
  • 存储编排
  • 批处理:提供一次性任务,定时任务;满足批量数据处理和分析的场景

3.2 K8S 特点

  • 可移植 : 支持公有云,私有云,混合云,多重云(multi-cloud)
  • 可扩展 : 可根据业务流量情况快速扩展kubernetes集群的节点数量。
  • 自愈 : 自动发布,自动重启,自动复制,自动扩展
  • 进程协同 :利用复合应用保证应用和容器一对一的模型。

4. K8s 集群架构与组件

4.1 K8s 集群架构

  • 集群架构 Shell Kubernetes集群包含有节点代理`kubelet`和`Master组件`(APIs, scheduler, etc),一切都基于分布式的存储系统。 一个kubernetes集群主要是由 控制节点(master)、工作节点(node)构成,每个节点上都会安装不同的组件。 下面这张图是Kubernetes的架构图。
  • 控制节点:

    ApiServer : 资源操作的唯一入口,接收用户输入的命令,提供认证、授权、API注册和发现等机制

    Scheduler : 负责集群资源调度,按照预定的调度策略将Pod调度到相应的node节点上

    ControllerManager : 负责维护集群的状态,比如程序部署安排、故障检测、自动扩展、滚动更新等

    Etcd :负责存储集群中各种资源对象的信息(默认的数据库,自己可以配置修改的,比如配 mysql )

    工作节点Node :

    Kubelet : 负责维护容器的生命周期,即通过控制docker,来创建、更新、销毁容器

    KubeProxy : 负责提供集群内部的服务发现和负载均衡

    Docker : 负责节点上容器的各种操作

Shell # 大致工作原理

kubectl 和web UI接入我们master节点后,scheduler调度器将任务交给api server, 通过api server 把任务写入 etcd 存储服务器,然后交给node节点执行 控制器,它们就是维护我们的副本的数目的或者叫做我们的期望值的,一旦它的副本数不满足我们的期望值,replication controller就会将它改写成 我们的期望值(创建或删除Pod数)

# 以安装nginx服务说明K8S组件调用关系: 首先要明确,一旦kubernetes环境启动之后,master和node都会将自身的信息存储到etcd数据库中

1. 一个nginx服务的安装请求会首先被发送到master节点的apiServer组件

2. apiServer组件会调用scheduler组件来决定到底应该把这个服务安装到哪个node节点上 在此时,Scheduler调度器会从etcd中读取各个node节点的信息,然后按照一定的算法进行选择,并将结果告知apiServer,分发给那个node

3. apiServer调用controller-manager(控制器)去调度Node节点安装nginx服务

4. kubelet接收到指令后,会通知docker,然后由docker来启动一个nginx的pod pod是kubernetes的最小操作单元,容器必须跑在pod中,此时nginx服务就已经跑起来了。

5. 一个nginx服务就运行了,如果需要访问nginx,就需要通过kube-proxy来对pod产生访问的代理

4.2 K8s 核心组件详细说明

  • 核心组件说明
  • #控制器,它们就是维护我们的副本的数目的或者叫做我们的期望值的,一旦它的副本数不满足我们的期望值,replication controller就会将它改写成 我们的期望值
  • # api 一切服务的访问入口,压力很大,为了减轻压力,每个请求下面就可以生成缓存
  • # etcd 是 paxos 键值对采用go 语言编写的键值对 数据库。 etcd 的官方 将它 定位成一个 可信赖的分布式键值存储服务器,它能够为整个分布式集群存储一些关键数据,协助分布式集群的正常运转。 可信赖:本身可以完成集群化 分布式:扩容缩非常方便 正常运转:保存我们的整个分布式集群的需要持久化的配置文件、配置信息,一旦我们的集群死亡后,我们可以借助到etcd 里面的一些信息,进行数据恢复 ectd 里面有2个版本,一个是 v2版,一个是v3版。v2版会将数据全部写入 内存中,v3 版本会引入本地卷的持久化操作(关机以后并不会造成数据损坏) 推荐使用kubernetes 集群中etcd v3, V1.11包含之前自带的的etcd是不支持V3的。 ETCD 键值数据库 是基于HTTP,进行的C/S开发的, 他有 这些组件 Raft:存储我们的读写信息的(所有的信息都存在这里) WAL:预写日志:为了防止Raft里面的信息出现损坏,还有WAL预写日志 (如果想对里面的数据进行更改,需要先生成一个日志,WAL先存一下,并且会定时的对这些日志进行完整的备份[完整+临时备份]) Entry: Snapshot:日志备份完整备份+增量备份
  • # node 节点:安装 kubelet 、kube proxy、 container(Docker) 在Node节点上实现Pod网络代理,维护网络规则和四层负载均衡工作。 kubelet:会跟我们的CRI(C 容器;R 运行环境; I 接口)---这里就是我们的Dokcer表现形式 。它会和我们的Docker进行交互,操作Docker去创建对应的容器[就是Kubelet维持我们Pod的生命周期] Kube proxy:相当于SVC,可以进行负载操作。也就意味着如何实现Pod与Pod之间如何访问,包括负载均衡。它的默认操作时firewall,操作防火墙,实现对Pod的映射。(新版本中还支持IPVS 实现负载均衡)
  • # 总结这些节点 api server:所有服务访问统一入口 CrontrollerManager:维持副本期望数 Scheduler:负责介绍任务,选择合适的节点进行分配任务。 etcd:键值对数据库,存储K8S集群所有重要信息(持久化) kubelet:直接跟容器引擎交互实现容器 的 生命周期管理 kube-proxy:负责写入规则至iptables(firewall)、ipvs(负载均衡) 实现服务映射访问的
  • 其它组件介绍
  • #CoreDNS : 可以为集群中的svc 创建一个域名IP的对应关系解析
  • #Dashboard: 给k8s提供一个B/S 结构访问体系 #Ingress controller: 官方实现了四层代理,Ingress 可以实现七层代理
  • #Federation: 提供一个可以跨越集群中心多k8s 统一管理功能
  • #Prometheus: 提供k8s 集群的监控能力
  • #ELK: 提供k8s 集群日志 统一 分析接入平台

5. K8s 核心概念

5.1 Master 集群控制节点

  • 每个集群至少一个master节点负责集群的管理

5.2 Node 工作负载节点

  • 由masster 分配容器到这些node节点上,然后node 节点上的docker 负责容器运行

5.3 Pod kubernetes的最小控制单元

  • **自主式pod ** Shell Pod是在K8s集群中运行部署应用或服务的最小单元(原子单元),它是可以支持多容器的。 只要我们定义了一个Pod,它就会自动启动一个容器---pause的网络栈。也就意味着同一个Pod 容器间的端口不能冲突 一个Pod里封装了很多个容器,他们共用一个pause,共用存储卷

5.4 Controller 控制器Pod

  • 控制器,通过它来实现对pod的管理,比如启动pod、停止pod、伸缩pod的数量等等
  • K8S内核提供了众多的pod控制器,常用的有: Shell Deployment 部署(暴露在最外面的) DaemonSet 要求每一个运行节点都启动一个 ReplicaSet StatefulSet Job Cronjob

5.4.1 复制控制器(Replication Controller,RC)— 确保预期的Pod副本数量

  • RC 控制器 Shell Replication Control1er 用来确保容器应用的副本数始终保持在用户定义的副本数,即如果有容器异常退出,会自动创建新的Pod 来替代;而如果异常多出来的容器也会自动回收。在新版本的Kubernetes 中建议使用ReplicaSet来取代 ReplicationControl1e

5.4.2 副本集(Replica Set,RS)— 确保预期的Pod副本数量

  • RS副本集 Shell ReplicaSet跟Replication Controller没有本质的不同,只是名字不一样,并且ReplicaSet支持集合式的selector 虽然ReplicaSet可以独立使用,但一般还是建议使用 Deployment来自动管理ReplicaSet ,这样就无需担心跟其他机制的不兼容问题(比如 ReplicaSet不支持rolling update 滚动更新但 Deployment支持)

5.4.3 HPA

  • HPA
  • HPA监控我们的RS,当我们的CPU达到80后(CPU>=80),他就会新建Pod,最多创建10个,最少保留2个。 如果高于80,就创建,小于80不在创建。

5.4.4 StatefulSet —为了解决有状态服务的问题

  • StatefulSet

StatefulSet是为了解决有状态服务的问题(对应 Deployments 和 ReplicaSets是为无状态服务而设计), 其应用场景包括: 1.稳定的持久化存储,即 Pod重新调度后还是能访问到相同的持久化数据,基于PVC来实现 2.稳定的网络标志,即 Pod重新调度后其 PodName和 HostName不变,基于 Headless Service(即没有Cluster IP的Service )来实现 3.有序部署,有序扩展,即 Pod是有顺序的,在部署或者扩展的时候要依据定义的顺序依次依次进行(即从О到N-1,在下一个Pod运行之前所有之前的 Pod必须都是Running 和 Ready状态),基于init containers来实现 4.有序收缩,有序删除(即从N-1到0>

5.4.5 部署(Deployment)

  • Deployment

DaemonSet确保全部(或者一些)Node 上运行一个Pod 的副本。当有Node加入集群时,也会为他们新增一个Pod 。当有Node从集群移除时,这些 Pod 也会被回收。删除 DaemonSet将会删除它创建的所有Pod 运行集群存储daemon,例如在每个Node 上运行glusterd、cepho. 在每个Node上运行日志收集daemon,例如fluentd、logstash。 在每个Node上运行监控daemon,例如Prometheus Node Exporter

5.4.6 Job、Cron Job 负责批处理任务

  • Job、Cron Job

Shell Job 负责批处理任务,即仅执行一次的任务,它保证批处理任务的一个或多个Pod 成功结束 Cron Job管理基于时间的 Job,即: 在给定时间点只运行一次 周期性地在给定时间点运行

5.5 服务发现(Service)

  • pod 对外服务的统一入口,可以维护同一类的多个Pod

在K8S里,虽然每个POD都会被分一个单独的IP地址,但这个IP地址会随着POD的销毁而消失,Service 就是来解决这个问题的核心概念 一个service 可以看作一组提供相同服务的Pod的对外访问接口 Service 作用于哪些Pod 是通过标签选择器来定义的 一个 Service 在 Kubernetes 中是一个 REST 对象,和 Pod 类似。 像所有的 REST 对象一样, Service 定义可以基于 POST 方式,请求 apiserver 创建新的实例。

5.6 Lable 标签

  • 标签,用于对Pod进行分类,同一类POD会拥有相同的标签
  • 附加到某个资源上,用于关联对象、查询和筛选

给资源打上标签后,可以使用标签选择器过滤指定的标签 标签选择器目前有2个:一个是基于 等值关系(等于、不等于) 一个是 基于集合关系(属于、不属于、存在) 许多资源支持内嵌标签选择器 字段 matchLabels matchExpressions 一个合法的标签应该是 字母和数字、下划线、虚线"-"、点"." 开头和结尾必须是字母或数字的形式组成。标签值最多63个字符

5.7 Ingress

  • Ingress是授权入站连接到达集群服务的规则集合。
  • 在K8S集群里,工作在应用层,对外暴露接口。
  • 可以调动不同业务域,不同URL访问路径的业务流量

你可以给Ingress配置提供外部可访问的URL、负载均衡、SSL、基于名称的虚拟主机等。用户通过POST Ingress资源到API server的方式来请求ingress。 Ingress controller负责实现Ingress,通常使用负载平衡器,它还可以配置边界路由和其他前端,这有助于以HA方式处理流量。

5.8 NameSpace 命名空间

  • 用来隔离pod 的运行环境

随着项目怎多,人员增加,集群规模的扩大,需要一种能够隔离K8S内各种"资源",都应该有自己的"名称"。 Kubernetes可以使用Namespaces(命名空间)创建多个虚拟集群。 Namespace为名称提供了一个范围。资源的Names在Namespace中具有唯一性。 不同名称空间的内部"资源" ,名称可以相同,相同名称空间内的同种 "资源","名称"不能相同 合理的使用K8S的名称空间,使得集群管理员能够更好的对付交付 到K8S里的服务进行分类管理和浏览 K8S里默认存在的名称空间有 default、kube-system、kube-public 查询k8s 里特定"资源" 要带上相应 的名称空间

6.K8S 的网络通讯方式

  • K8S 的网络模型 假定了所有POD都在一个可以直接连通的扁平的网络空间(扁平化:所有的POD都可以通过对方的IP互相访问),在这里GCE(Google Compute Engine) 里面是现成的网络模型.
  • K8S假定这个网络模型已经存在,而在私有云里搭建K8S集群,就不能假定这个网络已经存在了。
  • 所以,我们需要个网段假设,将不同节点上的Docker容器之间的互相访问先打通,然后在运行Kubernetes

6.1 同一个Pod 内的多个容器之间通讯:localhost

  • 同一个Pod 内部通讯,共享一个网络命名空间,共享一个linux协议栈

6.2 各个Pod之间的通讯:Overlay Network

  • 不同机器,上面运行的Docker容器IP一定不能冲突,

  • # 在k8s中,其实我们的谷歌没有对自己的k8s做了很强定义,它允许我们通过CNI接口,去接入我们自己的想要达到的一个网络方案。
  • # 其中Flannel 使我们在k8s里最常用的一种解决网络扁平化的一种方案,符合我们CNI接口。
  • # Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务,简单来说,它的功能是让集群中的不同节点主机创建的 Docker容器都具有全集群唯一的虚拟IP地址。而且它还能在这些IP地址之间建立一个覆盖网络(Overlay Network),通过这个覆盖网络,将数据包原封不动地传递到目标容器内。
  • # 不同物理机器上面运行的Docker 容器IP一定不能冲突。在Docker里面我们可以修改配置文件,修改网段。那么Flannel是怎么解决的。
  • # 这里有2台物理主机,运行了4个Pod。一台物理机上运行了webapp2、webapp1 2个Pod ,另一台物理主机上运行了 webapp3、Backend 2个接点。他们的网络架构是 Backend(前端接点)、webapp1、webapp2、webapp3,所有流量访问到Backend上,它去经过自己的网关去处理,把什么样的请求分配到什么样的服务上。
  • # 这样就意味着。webapp2 和backend通讯,就需要跨主机通讯了,以及 webapp3 和backend通讯,就是2个同主机的不同Pod通讯了。2种不同的通信到底如何解决?
  • # 首先在我们真实服务器上,我们会安装一个Flanneld的守护进程,这个进程会监听一个端口,这个端口用于后续监听接受或转发数据包 的一个端口。一旦这个Flanneld 进程启动后,它会开启一个 Flanneld 0 的网桥,网桥Flanneld 0 专门会手机网桥Docker0 转发出来的数据报文。然后Docker0 会分发自己的IP到对应的pod上,
  • # 如果是同一台主机上 的两个Pod 互相通信,它走的是Docker0网桥。
  • # 如何跨主机,通过对方的IP直接到达?
  • # 假设 webapp2 与Backend 通讯,源地址是10.1.15.2/24 目标地址是 10.1.20.3/24。 因为不是同一个网段,所以首先 webapp2 会发送 自己的网关Docker0 10.1.15.1/24,然后 Flannel0 10.1.15.0/16 接受docker0 的报文,然后发送给Flanneld进程。此时Flanneld进程会从 etcd 获取路由,并写入当前的主机路由,经过Flanneld封装 后发送。Flanneld 封装数据包 先mac封装,然后 封装 源IP 192.168.10.11 目的IP 192.168.10.12 ,接着封装UDP协议,在封装 源IP 10.1.15.2 目的IP 10.1.20.3。然后发送到 物理机 192.168.10.12 上面的Flannel0 ,Flanneld 进程会截取报文。然后会拆封,然后转发到 Docker0,看到的是源地址是10.1.15.2/24 目标是 10.1.20.3的地址的数据包。然后发给Blackend

ETCD 之 Flannel提供说明:

  • 存储管理 Flannel 可分配的 IP地址段资源(也就意味着Flannel 在启动后,会向etcd 插入可以分配的网段,并记录分配的pod地址,防止 已分配的网段再次被利用,造成地址冲突)
  • 监控ETCD中每个Pod 的实际地址,并在内存中建立维护Pod节点路由表

6.3 Pod 与Service 之间的通讯:各节点的Iptables(LVS转发)

  • Pod 致Service 的网络 :目前基于性能考虑,全部为iptables 维护和转发

6.4 通讯总结

  • 通在同一台机器,由Docker0网桥直接转发请求只Pod2,不需要进过Flannel
  • Podl至 Pod2:
    • Podl与 Pod2不在同一台主机,Pod的地址是与docker0在同一个网段的,但dockerO网段与宿主机网卡是两个完全不同的IP网段,并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来,通过这个关联让Pod可以互相访问
    • Pod1 与 Pod2在同一台机器,由 Docker0网桥直接转发请求至 Pod2,不需要经过 Flannel 演示
  • Pod 致Service 的网络 :目前基于性能考虑,全部为iptables 维护和转发
  • Pod 到外网 : Pod 向外网发送请求,查找路由表,转发数据包到 宿主机的网卡,宿主网卡完成路由选择后,iptables执行Masqureade,把源IP 更改为宿主网卡的IP,然后想外网服务器发送请求。
  • 外网发送Pod : service

7.K8s里面的三张网络

  • 三种网络

  • # 节点网络 就是我们真实的物理网卡 # Pod 和service 都是虚拟网络

二、总结

  • K8S概念很是复杂,这里先简单的介绍下k8s基础概念,后续接着更新k8s 部署,已及更深参次的介绍k8s。初次里面涉及的概念,一定要搞清楚,偶尔面试会被问到


 

   
52736 次浏览       22
相关文章

聊聊云原生和微服务架构
Serverless:微服务架构的终极模式
如何实现微服务架构下的分布式事务?
微服务下的数据架构设计
相关文档

微服务和云原生应用
微服务架构原理和设计方法
0到3000万用户微服务之旅
微服务在微信后台的架构实践
相关课程

微服务架构设计与实践
领域驱动+微服务架构设计
云计算、微服务与分布式架构
云平台与微服务架构设计

最新活动计划
SysML和EA系统设计与建模 7-26[特惠]
Python、数据分析与机器学习 8-23[特惠]
软件架构设计方法、案例与实践 8-23[特惠]
嵌入式软件架构设计 8-22[线上]
Linux内核编程及设备驱动 7-25[北京]
 
 
最新文章
云原生架构概述
K8S高可用集群架构实现
容器云管理之K8S集群概述
k8s-整体概述和架构
十分钟学会用docker部署微服务
最新课程
云计算、微服务与分布式架构
企业私有云原理与构建
基于Kubernetes的DevOps实践
云平台架构与应用(阿里云)
Docker部署被测系统与自动化框架实践
更多...   
成功案例
北京 云平台与微服务架构设计
通用公司GE Docker原理与实践培训
某军工研究单位 MDA(模型驱动架构)
知名消费金融公司 领域驱动设计
深圳某汽车企业 模型驱动的分析设计
更多...