Kubernetes k8s

一个开源的容器编排引擎，用来对容器化应用进行自动化部署、扩缩和管理。

从架构设计层面，k8s能很好的解决可用性，伸缩性；从部署运维层面，服务部署，服务监控，应用扩容和故障处理，k8s都提供了很好的解决方案。

k8s主要包括以下几点：

服务发现与调度
- Kubernetes 可以把用户提交的容器放到 Kubernetes 管理的集群的某一台节点上去。Kubernetes 的调度器是执行这项能力的组件，它会观察正在被调度的这个容器的大小、规格。比如说容器所需要的 CPU 以及 memory，然后在集群中找一台相对比较空闲的机器来进行一次 placement，也就是一次放置的操作。
存储编排
自动部署和回滚
服务自愈
- Kubernetes 有一个节点健康检查的功能，它会监测这个集群中所有的宿主机，当宿主机本身出现故障，或者软件出现故障的时候，这个节点健康检查会自动对它进行发现。Kubernetes 会把运行在这些失败节点上的容器进行自动迁移，迁移到一个正在健康运行的宿主机上，来完成集群内容器的一个自动恢复。
服务弹性扩容
横向扩容
- Kubernetes 有业务负载检查的能力，它会监测业务上所承担的负载，如果这个业务本身的 CPU 利用率过高，或者响应时间过长，它可以对这个业务进行一次扩容。比如下面的例子，黄颜色的过度忙碌，Kubernetes 可以把黄颜色负载从一份变为三份。接下来，它就可以通过负载均衡把原来打到第一个黄颜色上的负载平均分到三个黄颜色的负载上去，以此来提高响应的时间。
存储卷挂载

一、概述

1. 部署发展史

在这里插入图片描述

二、k8s架构

在这里插入图片描述

1. Master

API Server：处理 API 操作的，Kubernetes 中所有的组件都会和 API Server 进行连接，组件与组件之间一般不进行独立的连接，都依赖于 API Server 进行消息的传送；
Controller：控制器，用来完成对集群状态的一些管理。比如刚刚我们提到的两个例子之中，第一个自动对容器进行修复、第二个自动进行水平扩张，都是由 Kubernetes 中的 Controller 来进行完成的；
Scheduler：是调度器，完成调度的操作，比如把一个用户提交的 Container，依据它对 CPU、对 memory 请求大小，找一台合适的节点，进行放置；
etcd：是一个分布式的一个存储系统，API Server 中所需要的这些原信息都被放置在 etcd 中，etcd 本身是一个高可用系统，通过 etcd 保证整个 Kubernetes 的 Master 组件的高可用性。

API Server，它本身在部署结构上是一个可以水平扩展的一个部署组件；Controller 是一个可以进行热备的一个部署组件，它只有一个 active，它的调度器也是相应的，虽然只有一个 active，但是可以进行热备。

2. 节点

Kubernetes 的 Node 是真正运行业务负载的，通过将容器放入在节点（Node）上运行的 Pod 中来执行工作负载。节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。每个节点包含运行 Pod 所需的服务；这些节点由控制面负责管理。
每个业务负载会以 Pod 的形式运行。
一个 Pod 中运行的一个或者多个容器，真正去运行这些 Pod 的组件的是叫做 kubelet，也就是 Node 上最为关键的组件，它通过 API Server 接收到所需要 Pod 运行的状态，然后提交到下面这个 Container Runtime 组件中。
在这里插入图片描述
Node上的四个组件：

在 OS 上创建容器所需要运行的环境，最终把容器或者 Pod 运行起来，也需要对存储跟网络进行管理。Kubernetes 并不会直接进行网络存储的操作，他们会靠 Storage Plugin 或者是网络的 Plugin 来进行操作。用户自己或者云厂商都会去写相应的 Storage Plugin 或者 Network Plugin，完成存储操作或网络操作。
在 Kubernetes 自己的环境中，也会有 Kubernetes 的 Network，它是为了提供 Service network 来进行搭网组网的。真正完成 service 组网的组件的是 Kube-proxy，它是利用了 iptable 的能力来进行组建 Kubernetes 的 Network，就是 cluster network。

Kubernetes 的 Node 不会直接和 user 进行 interaction，它的 interaction 只会通过 Master。而 User 是通过 Master 向节点下发这些信息的。Kubernetes 每个 Node 上，都会运行我们刚才提到的这几个组件。

Kubernetes 架构中的组互相进行 interaction 举例：
在这里插入图片描述

用户通过 UI 或者 CLI 提交一个 Pod 给 Kubernetes 进行部署，这个 Pod 请求首先会通过 CLI 或者 UI 提交给 Kubernetes API Server，下一步 API Server 会把这个信息写入到它的存储系统 etcd，之后 Scheduler 会通过 API Server 的 watch 或者叫做 notification 机制得到这个信息：有一个 Pod 需要被调度。
这个时候 Scheduler 会根据它的内存状态进行一次调度决策，在完成这次调度之后，它会向 API Server report 说：“OK！这个 Pod 需要被调度到某一个节点上。”
这个时候 API Server 接收到这次操作之后，会把这次的结果再次写到 etcd 中，然后 API Server 会通知相应的节点进行这次 Pod 真正的执行启动。相应节点的 kubelet 会得到这个通知，kubelet 就会去调 Container runtime 来真正去启动配置这个容器和这个容器的运行环境，去调度 Storage Plugin 来去配置存储，network Plugin 去配置网络。

三、Kubernetes 的核心概念与它的 API

1. 核心概念

Pod

Pod 是 Kubernetes 的一个最小调度以及资源单元
由一个或多个容器组成。用户可以通过 Kubernetes 的 Pod API 生产一个 Pod，让 Kubernetes 对这个 Pod 进行调度，也就是把它放在某一个 Kubernetes 管理的节点上运行起来。一个 Pod 简单来说是对一组容器的抽象，它里面会包含一个或多个容器。

比如这个图片：包含了两个容器，每个容器可以指定所需要资源大小。比如说，一个核一个 G，或者2个核2个 G。
在这个 Pod 中也可以包含一些其他所需要的资源：比如说我们所看到的 Volume 卷这个存储资源；比如说我们需要 100 个 GB 的存储或者 20GB 的另外一个存储。
在这里插入图片描述

Volume

Volume 就是卷的概念，它是用来管理 Kubernetes 存储的

用来声明在 Pod 中的容器可以访问文件目录的，
一个卷可以被挂载在 Pod 中一个或者多个容器的指定路径下面。
一个 Volume 可以支持多种的后端的存储。比如说 Kubernetes 的 Volume 就支持了很多存储插件，它可以支持本地的存储，可以支持分布式的存储，比如说像 ceph，GlusterFS ；它也可以支持云存储，比如说阿里云上的云盘、AWS 上的云盘、Google 上的云盘等等。

Deployment

Deployment 是在 Pod 这个抽象上更为上层的一个抽象

定义一组 Pod 的副本数目、以及这个 Pod 的版本。一般大家用 Deployment 这个抽象来做应用的真正的管理，而 Pod 是组成 Deployment 最小的单元。
Kubernetes 是通过 Controller去维护 Deployment 中 Pod 的数目，它也会帮助 Deployment 自动恢复失败的 Pod。
比如可以定义一个 Deployment，这个 Deployment 里面需要两个 Pod，当一个 Pod 失败的时候，控制器就会监测到，它重新把 Deployment 中的 Pod 数目从一个恢复到两个，新生成一个 Pod。
通过控制器，完成发布的策略。比如说进行滚动升级，进行重新生成的升级，或者进行版本的回滚。

Service

Service 提供了一个或者多个 Pod 实例的稳定访问地址。
比如一个 Deployment 可能有两个甚至更多个完全相同的 Pod。对于一个外部的用户来讲，访问哪个 Pod 其实都是一样的，所以它希望做一次负载均衡，在做负载均衡的同时，我只想访问某一个固定的 VIP，也就是 Virtual IP 地址，而不希望得知每一个具体的 Pod 的 IP 地址。
Service 支持多种访问方式实现，Kubernetes 支持 Cluster IP，上面我们讲过的 kuber-proxy 的组网，它也支持 nodePort、 LoadBalancer 等其他的一些访问的能力。

Namespaces

Namespace 是用来做一个集群内部的逻辑隔离的，它包括鉴权、资源管理等。
Kubernetes 的每个资源都属于一个 Namespace，比如刚才讲的 Pod、Deployment、Service
同一个 Namespace 中的资源需要命名的唯一性
不同的 Namespace 中的资源可以重名。
Namespace 一个用例，比如像在阿里巴巴，内部会有很多个 business units，在每一个BU 之间，希望有一个视图上的隔离，并且在鉴权上也不一样，在 cuda 上面也不一样，可以用 Namespace 给每一个 BU 提供一个他所看到的这么一个看到的隔离的机制。

四、Kubernetes 的 API

从 high-level 上看，Kubernetes API 是由 **HTTP+JSON **组成的：用户访问的方式是 HTTP，访问的 API 中 content 的内容是 JSON 格式的。
Kubernetes 的 kubectl 也就是 command tool，Kubernetes UI，或者有时候用 curl，直接与 Kubernetes 进行沟通，都是使用 HTTP + JSON 这种形式。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mfbz.cn/a/359277.html

如若内容造成侵权/违法违规/事实不符，请联系我们进行投诉反馈qq邮箱809451989@qq.com，一经查实，立即删除！