Kubernetes 核心原理及实战中使用方法

欢迎关注公众号K的笔记阅读博主更多优质学习内容
K的笔记公众号

认识 kubernetes 架构及应用场景

kubernetes(k8s) 在企业中的应用场景

构建自动化运维平台

(1) 中小型企业,使用 k8s 构建一套自动化运维平台(降本增效)
(2) 大型互联网公司更要使用,实现更高效的运作方式

充分利用服务器资源

怎么理解充分利用服务器资源这一条呢,我们举个例子:假设并发量200请求,服务器是两核心CPU,4G内存,其中静态请求150个,比如访问CDN、nginx、缓存等,动态请求50个,主要是访问数据库,把数据读入内存,我们来估算服务器资源(只考虑内存,不考虑程序员RT与CPU切换时间):

静态+动态 = 150*2M + 50 *10M = 800M
也就是说200个请求占用了800M内存

我们可以估算这台服务器的并发能力QPS为 200*4 = 8000,但实际上 800 QPS 是无法达到的,我们需要考虑 response time,cpu切换时间,内存等等,因此实际上我们会给它安排 300 QPS,此时先然无法充分利用服务器资源,有很多资源被浪费掉了。而 k8s 使用类似 Docker 的容器化方式,也就是我们在其中部署多个容器,将服务器资源做隔离,容器中部署的就是 web 服务。

服务无缝衔接

那么服务的无缝迁移又该怎么理解呢?首先我们开发时应该有三种环境,分别是是开发环境、测试环境和生产环境。在开发 web 项目时有许多配套服务,在测试环境中这些环境也必须存在,测试完之后产品就可以上线,但这时会出现一个问题:项目在测试时没有毛病,但一旦上市生产就出现了很大的问题,这经常是环境的不一致性造成的,这时候往往就会花费大量精力去调试环境,非常麻烦,而容器化方式可以做到服务无缝迁移。也就是说我们可以把 JDK、MQ、ES、MySQL 等做成一个个镜像,这些镜像可以脱离我们的依赖环境,因此这些镜像可以做到无缝迁移。

服务部署模式变迁&服务部署模式变化的思考

我们考虑下面几个问题:

服务部署模式是怎么变迁的。

  1. 物理机部署:就是直接把服务部署到物理机上(不能充分利用物理机资源)
  2. 虚拟化(虚拟机)方式,也就是通过虚拟机将物理资源进行隔离部署服务,将服务部署到虚拟机上,但虚拟机本身就非常占用资源,因此我们寻求一种更好的方式
  3. 使用容器化方式进行部署(容器更轻量级,运行更快)

服务部署模式变化,带来哪些问题?

  1. 前提条件:SOA架构,微服务架构的模式下,项目拆分越来越多,服务越来越多,这么多服务我们是怎么管理?

    • 虚拟机服务部署方式(openstack)

    • 容器化部署模式(k8s)

    容器我们可以认为是一个更轻量级的虚拟机,使用了与虚拟机不同的技术,因此与openstack用于管理虚拟机类似, k8s 就是用来管理容器的。

  2. 面临问题:

    • 如何对服务进行横向扩展(不能 简单地加机器,会影响服务)

    • 容器宕机如何解决,数据怎么恢复

    • 重新发布新的版本如何在线上快速更新,更新后不影响业务(k8s可以做滚动更新)

    • 如何监控容器(容器出现问题怎么办)

    • 容器如何调度创建

    • 数据安全性如何保证

云架构 & 云原生

云和 k8s 是什么关系

  • 云就是使用容器构建的一套服务集群网络,云由大量容器构成,不同容器有不同功能
  • k8s 就是用来管理云中的容器

云架构

iaas 基础设施即服务
用户:可以租用(购买|分配权限)云主机,用户就不需要考虑网络,DNS,硬件环境方面的问题。
运营商:(私有云或公有云平台)提供网络,存储,DNS(基础设施服务)
paas 平台即服务
MYSQL\ES\R等服务都由平台提供了
saas 软件即服务(目前很多系统都是该系统)
钉钉:给每个公司提供一个系统,每个公司使用独立一套功能
财务管理软件:维护交给运营商维护,用户只需要使用其中的功能即可
serverless 无服务
 站在用户角度:不需要服务器,用户只需要使用云服务器即可,在云服务器所有基础环境 ,软件环境都不需要 用户自己安装
 未来:服务开发都是 serverless,企业都构建了自己的私有云环境,或者使用公有云环境(阿里云)
 	阿里将所有服务部署到云端之后,效率提升了60%

云原生

就是为了让应用程序(项目、服务软件)都 运行在云上的解决方案,这样的方案叫做云原生。
特点
(1)容器化 —— 所有服务部署都必须部署在容器中
(2)微服务 —— web 服务架构、微服务架构
(3)CI、CD —— 可持续交互与可持续部署
(4)DevOps —— 开发与运维密不可分

kubernetes 架构原理

1)kubernetes 是 Google 使用 go 语言开发,原来的系统是 borg 系统(也是云平台管理工具),Docker后来自己开发了容器管理平台 Docker Swarm,Google 表示不服,因此参照 borg 架构开发了 k8s 架构

2)k8s 架构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1FX9K7FA-1591151340036)(./Pic/k8s/arch1.jpg)]

关系:一个 master 对应多个 node 节点

master 节点

  1. api server:k8s 网关,所有指令请求都必须经过 api server
  2. scheduler:调度器,使用调度算法,将请求资源调度给某一个 node 节点
  3. controller 控制器:维护 k8s 资源对象(添加、删除、更新、修改)
  4. etcd:存储资源对象,服务的注册与发现

node 节点

  1. docker:运行容器的基础环境,容器引擎
  2. kuberlet:在每个 node 节点都存在一份,在 node 节点上的资源操作指令由其执行
  3. kube-proxy:代理服务,负载均衡
  4. fluentd:日志收集服务
  5. pod:是 k8s 管理的基本单位,内部是容器,也即是 k8s 不直接管理容器,而是管理 pod

深入认识 kubernetes 核心组件原理

pod的核心原理

k8s的作用:k8s是用来管理容器的,但不直接操作容器,最小操作单元是pod(间接地管理容器)
k8s的特点

  1. 一个master有一群node节点与之对应
  2. master节点不存储容器,只负责调度、网关、控制器、资源对象存储
  3. 容器是存储在node节点(容器是存储在pod内部)
  4. pod内部都可以有一个容器,或者是多个容器
  5. kubelet负责本地的pod维护
  6. kube-proxy负责在多个pod之间做负载均衡

pod是什么呢:pod也是一个容器,但这个容器中装的是docker创建的容器,也就是pod是用来封装容器的容器,pod是一个虚拟化分组(pod有自己的地址,主机名),相当于一台独立的沙箱环境(主机),可以封装一个容器或多个容器

pod用来干什么:通常情况下,在服务部署时使用pod来管理一组相关服务(一个pod要么部署一个服务,要么部署一组相关的服务),所谓的一组相关的服务,即为链式调用的调用链路上的服务。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cieWbksy-1591151340037)(./Pic/k8s/pod1.png)]

web服务集群如何实现:只需要复制多方pod的副本即可,这也是k8s管理的先进之处,k8s如果继续扩容、缩容,只需要控制pod的数量即可

pod底层网络,数据存储是如何进行的:pod内部容器创建之前必须先创建pause容器,服务容器之间的访问使用localhost访问,性能非常高,实际就像访问本地服务一样

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tIbIoE1Q-1591151340039)(./Pic/k8s/pod2.png)]

ReplicaSet副本控制器

什么叫做副本控制器用于控制pod副本的数量,使副本数量与预期数量保持一致。例如,我们提前设置replicas=3(有三个副本),因此创建三个pod。当有一个pod宕机之后,k8s会立刻创建一个新的,保证副本数量等于三个,这就是副本控制器的作用——永远保证副本数量为设定值。

副本控制器能通过标签选择器选择维护一组相关的服务(它自己的服务),那么它要怎么判断是自己的服务呢?这里就通过标签选择,比如

selector:
	app = web
    release = stable

ReplicationController和ReplicaSet两个副本控制器有什么区别

  1. ReplicaSet
    • 单选
    • 复合选择
  2. ReplicationController
    • 单选

在新版的k8s中,推荐使用Replicaset作为副本控制器(功能更强大),ReplicationController不再使用

Deployment资源部署对象

  • 服务部署结构模型
  • 滚动更新

虽然在企业中我们采用ReplicaSet作为副本控制器,但在实际中项目不断更新,项目的版本将会不停的发版,版本的变化如何做到服务的更新呢?我们做的是滚动更新,如下图,每当发布一个新的版本,每更新一个POD,就要干掉原有的POD。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AYqWfw7n-1591151340040)(./Pic/k8s/Deployment.png)]

那么滚动更新是由谁实现的呢?这就涉及到部署模型:因为事实上ReplicaSet是不支持滚动更新的,滚动更新是由Deployment支持的,通常两者一起使用,因此部署模型为如下结构:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DinzZ2cM-1591151340043)(./Pic/k8s/dep2.png)]

如果后一个版本出现问题,k8s也可以支持向前滚动。

StatefulSet部署有状态服务

StatefulSet和Deployment类似,区别就是StatefulSet是为了解决有状态服务容器化部署问题而产生的。

思考:MySQL使用容器化部署,存在怎样的问题?

  • 容器是有生命周期的,一旦宕机,数据丢失
  • pod部署:pod有生命周期,但重启pod集群副本时数据可能丢失

因此容器是不太适合部署数据这样的有状态服务的,对于k8s而言,不能使用Deployment模型来部署有状态服务,通常情况下Deployment用于部署无状态服务,对于有状态服务的部署使用StatefulSet。

什么是有状态什么是无状态呢?

  • 有状态服务
    • 有实时的的数据需要存储
    • 有状态服务集群中,把某一个服务抽离出去,一段时间后再加入机器网络,如果集群网络无法使用就被称为有状态服务
  • 无状态服务
    • 无实时的的数据需要存储
    • 有状态服务集群中,把某一个服务抽离出去,一段时间后再加入机器网络,对集群网络没有影响

底层的数据存储借助PVC文件系统,而StatefulSet会保证POD重新建立后,hostname不会发生变化,POD就可以通过hostname来关联数据

kubernetes 的服务的注册与发现(核心)

pod在生产环境中的访问流程

pod的结构:根据前面所说,pod相当于一个容器,有独立的ip地址,也有自己的hostname,利用namespace进行资源隔离,独立沙箱环境。同时pod内部封装的是容器,可以封装一个,也可以封装一组相关的容器。

pod网络:有自己独立的ip地址,pod内部容器之间访问采用localhost访问。

pod如何对外网提供服务

  • 前提思考:pod有PODID和hostname,pod是虚拟的资源对象(进程),没有对应的实体(物理机,物理网卡),单独的POD不能直接对外提供访问,对外提供访问一定要有物理机,通过端口访问
  • 解决方案:POD如果想要对外提供访问,必须绑定物理机的端口,(在物理及上开启端口,让这个端口和POD的端口建立映射),这样就可以通过物理机进行数据包的转发
  • 总结为步骤:①先通过物理机IP+port进行访问NODE节点;②数据包转发

pod如何实现负载均衡访问

一组相同的副本直接POD如何实现负载均衡访问,思考nginx能否做负载均衡:事实上pod是一个进程,是有生命周期的(宕机,版本更新),都会创建新的pod(ip地址发生变化,hostname发生变化),nginx做负载均衡不太合适,因为nginx不能识别出hostname的变化,因此在pod动态变化的前提下(且由于经常做滚动更新,变化速度比较快),nginx不能发现我们的服务。因此我们使用service VIP实现负载均衡。

利用service来实现负载均衡
  • POD IP:pod的ip地址
  • NODE IP:物理机的IP地址
  • cluster IP:虚拟化IP,是由k8s抽象出的service对象,这个service对象是一个VIP的资源对象

Kubernetes 这样定义Service :逻辑上的一组 Pod,一种可以访问Pod的策略,通常称之为微服务。 这一组 Pod 能够被 Service 访问到,通常是通过selector实现的。当我们调用某个服务时并不关心调用了哪个Pod,对外提供服务一组的 Pod 实际上可能会发生变化(是否能提供服务,或者在销毁中,或者在创建中),而Service 能够解耦这种关联。

在 Kubernetes 集群中,每个Node运行一个 kube-proxy代理进程。kube-proxy 负责为 Service实现了一种VIP(虚拟 IP)。

以下为Service资源对象:

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  labels:
    app: nginx
spec:
  type: ClusterIP
  ports:
    - port: 80
       targetPort: 80
  selector:
    app: nginx

Service如何实现负载均衡

我们知道了一组相关的port做负载均衡会使用虚拟IP来做数据包转发,但service是节点(资源对象)是怎么实现数据包的转发呢?

我们已知的

  1. service和pod都是一个进行,因此service也不能对外网提供服务
  2. service和pod之间可以直接进行通信,它们的通信属于局域网通信
  3. 把请求交给service后,service使用(ipstables,ipvs)来做数据包分发

访问步骤

  1. 在物理机上绑定端口
  2. 通过ip:port访问
  3. 访问完成之后将请求转交给service
  4. service将数据包分发给相应的pod

service对象是如何与pod建立关联的?

每一组相同的pod(副本)会有相同的标签,通过标签选择器(selector),service对一组相同的副本提供服务,如果是需要访问另一组,则需在创建一个service。因此不同的业务会有不同的service。然后service将对应的POD的IP地址存储到endpoints中,由此将service和相应的pod关联起来了。

当pod宕机或者发布了新的版本,service怎么发现pod发生了变化?

主要是依靠kube-proxy组件,k8s安装后每个节点都运行着这个组件。kube-proxy进程将监听所有的pod,一旦发现pod有变化,就会更新service中endpoint中的映射关系。

本文图片上传有些问题,若想获得更好的观看体验,欢迎访问我的个人博客主页 ~

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值