Kubernetes教程

时间:2020-01-09 10:41:07  来源:igfitidea点击:

Kubernetes也称为K8,由Google根据其在生产容器中的经验创建。
这是一个开源项目,是最好和最受欢迎的容器编排技术之一。

在理解Kubernetes之前,我们必须熟悉Docker容器,否则,如果我们是初学者,那么我们可能会觉得Kubernetes有点让人难以理解。
因此,我们将通过首先了解Docker和容器来开始我们的Kubernetes教程。

什么是Docker容器,为什么要使用它们?

  • 在正常的IT工作流程中,开发人员将开发新的应用程序。
    一旦应用程序开发完成,他们将把该应用程序交给运营工程师,然后由他们将其安装在生产服务器上并使其运行。

  • 如果运维工程师很幸运,他们甚至会得到一些准确的文档,其中包含开发人员的安装说明。
    到目前为止,一切都很好,而且生活很轻松。

  • 但是,当企业中有许多开发人员团队创建完全不同类型的应用程序时,事情变得有些失控,而所有开发人员团队都需要安装在相同的生产服务器上并其中运行。

  • 通常,每个应用程序都具有一些外部依赖性,例如,它是基于哪个框架构建的,使用的是什么库等等。
    有时,两个应用程序使用相同的框架,但彼此之间可能兼容或者不兼容,但版本不同。

  • 因此,安装某个应用程序的新版本本身可能是一个复杂的项目,并且通常需要数月的计划和测试

  • 但是,如今,我们必须发布补丁程序,并经常进行更新,这样开发和测试周期对于企业来说可能是非常冒险的。

使用虚拟机

第一个解决方案是使用"虚拟机"(VM)

  • 不必在同一台服务器上全部运行多个应用程序,而是打包并在每个VM上运行一个应用程序。

  • 这样,所有的兼容性问题都消失了,生活似乎又恢复了。

  • 但这带来了它自己的缺点,即每个VM需要大量资源,而大部分资源则由基础系统OS使用。

使用Docker容器

解决此问题的最终方法是提供比VM" Docker容器"轻得多的东西来进行救援。

  • 容器不虚拟化硬件,而是位于单个Linux实例的顶部。
    这使Docker可以避免与完整的硬件管理程序有关的大量膨胀。

  • 勿庸置疑Docker引擎(或者LXC进程)相当于更传统的VM中的虚拟机监控程序,它只是将进程封装在底层系统上。

  • Docker利用Linux内核的"命名空间"功能,其中命名空间将使在一个容器内运行的进程对于处理器或者在另一个容器内运行的用户不可见

  • 使用docker,开发人员现在可以将其应用程序,从属库,框架打包到一个容器中,以供测试人员或者操作工程师使用。

  • 对于测试人员和操作工程师来说,容器只是一个黑匣子,他们所需要的只是一个运行Docker的Linux操作系统,他们可以轻松部署该容器而不必担心配置该应用程序,因为这些容器已经包含正在运行的应用程序。

虚拟机与Docker容器

该镜像应具有自我解释性,以了解Docker和VMware架构之间的区别。

  • VM需要Hypervisor,该Hypervisor既可以安装在操作系统上,也可以直接安装在硬件上,而在安装docker之后可以部署容器。

  • VM需要安装一个单独的OS,以在Docker容器共享主机操作系统的同时部署应用程序,这就是它们轻巧的原因

  • 由于Docker与主机共享操作系统,因此Docker容器的启动时间非常短,而VM的启动时间相对较长

  • docker容器共享Linux内核,因此如果我们计划在同一Linux内核上运行多个应用程序,则非常合适,但是如果应用程序需要不同的操作系统,则必须使用VM

  • 由于VM不共享主机OS,因此它比Docker容器更安全。
    如果攻击者可以访问主机或者任何单个容器,则攻击者可能会利用所有容器。

  • 由于容器没有操作系统,因此它们使用相对较少的资源来执行应用程序,因此我们可以更有效地利用基础资源

容器编排

既然我们已经熟悉了容器,那么接下来我们需要了解container orchestration
总结一下,我们有一个Docker容器,容器中运行着某些应用程序。

  • 来自容器1的应用程序可能依赖于来自另一个容器的某些其他应用程序,例如生产环境中的数据库,消息,日志记录服务。

  • 我们可能还需要能够在高峰时段扩展容器的数量,例如,我确定我们必须熟悉假期期间的亚马逊销售,因为它们在所有产品上都有大量额外优惠。
    在这种情况下,他们需要为应用程序"扩展"其资源,以便能够处理更多用户。
    节日优惠结束后,他们将再次需要"缩减"带有应用程序的容器的数量。

  • 为了启用此功能,我们需要具有一组资源和功能的基础平台。
    该平台需要"协调"容器之间的连接,并根据负载自动按比例放大或者缩小。

  • 部署和管理容器的过程称为"容器编排"。

  • 因此," Kubernetes是一种容器编排技术",用于在集群环境中协调成千上万个容器的部署和管理。

  • 如今有多种类似的技术可供使用,Docker拥有自己的编排软件,即Docker Swarm,Google的Kubernetes和Apache的Mesos。

  • 应用程序现在"高度可用",因为现在我们在多个节点上拥有多个应用程序实例

  • 用户流量在各个容器之间实现负载均衡

  • 当需求增加时,可以在几秒钟内无缝地部署更多应用程序实例,并且当硬件资源用完时,我们能够在服务级别执行此操作,然后在不关闭应用程序的情况下上下扩展基础节点的数量使用一组声明性对象配置文件可以轻松完成所有这些操作。

Kubernetes体系结构

  • 一个" Kubernetes集群"由主节点和客户端节点设置组成,在该节点中,我们将拥有一个主节点或者"控制器"节点以及多个客户端节点(也称为"工人"节点或者奴才节点)。

  • Master是安装了Kubernetes的节点,负责在工作节点上对容器进行实际的编排。
    它将包含群集节点的所有信息,监视每个节点,如果工作节点发生故障,则它将工作负载从发生故障的节点移至另一个工作节点。

  • 节点是一个工作机,可以是安装了Kubernetes的物理机或者虚拟机。

  • Kubernetes不会将容器直接部署到工作节点中,而是将这些容器封装到称为" Pods"的Kubernetes对象中。

  • Pod是应用程序的单个实例,它们是我们可以在Kubernetes中创建和管理的最小可部署计算单元。

  • 我们将在这些容器中部署容器,其中我们将部署应用程序

以下是Kubernetes的基本架构图以及容器,吊舱和物理工作人员节点之间的关系,这些关系过去被称为Minion。

Kubernetes集群

Kubernetes集群中有三个主要组件,即节点,容器和容器。
我们已经深入了解了容器,因此其中我将介绍其余组件:

Master

  • 主机是Kubernetes的控制平面。

  • 它由几个组件组成,例如API服务器,调度程序和控制器管理器。

  • 主节点负责集群的全局状态,pod的集群级调度以及事件的处理。
    通常,所有主组件都在单个主机上设置。

  • 在考虑高可用性方案或者非常大的群集时,我们将需要具有主冗余。

节点Node(Minion)

  • 我们可以将它们视为容器客户端。

  • 这些是单独的主机(物理或者虚拟),将在其上安装Docker来托管托管集群中的不同容器

  • 每个节点都将运行ETCD(密钥对管理和通信服务,Kubernetes用于交换消息和报告集群状态)以及Kubernetes代理

Pod

  • Pod是一个或者多个容器的组,具有共享的存储/网络资源,以及有关如何运行容器的规范。

  • 我们并不是在提示某个AD连播始终包含多个容器,但AD连播通常只包含一个容器。

  • 关于pod的关键是,当pod确实包含多个容器时,它们都始终在单个工作程序节点上运行-它永远不会跨越多个工作程序节点

  • (由群集控制器)保证这些容器位于同一主机上,以便于资源共享

  • 在每个群集中为Pod分配了唯一的IP地址。
    这些使应用程序可以使用端口,而不必担心端口利用率冲突

  • Pod可以包含磁盘卷的定义或者共享,然后提供从该卷到Pod的所有成员(容器)的访问。

Kubernetes组件

在安装Kubernetes时,基本上,我们正在使用以下组件:

API服务器

  • API服务器充当Kubernetes的前端

  • 由于它是无状态的,因此可以轻松地水平扩展,并将所有数据存储在etcd集群中。

  • 用户,管理设备,命令行界面都与API服务器对话以与Kubernetes集群进行交互

etcd密钥库

  • 这是一个分布式可靠的键值存储

  • Kubernetes使用它来存储整个集群状态

  • 在小型瞬态群集中,etcd的单个实例可以与所有其他主组件一起在同一节点上运行。

  • 但是对于更大型的群集,通常具有三节点甚至五节点的etcd群集可实现冗余和高可用性。

  • 它负责在集群中实现锁,以确保主服务器之间没有冲突。

Scheduler调度器

Kube-Scheduler负责将Pod调度到节点中。
这是一项非常复杂的任务,因为它需要考虑多个交互因素,例如:

  • 资源需求

  • 服务要求

  • 硬件/软件策略约束

  • 节点亲和力和反亲和力规范

  • Pod亲和力和反亲和力规范

  • 污点和容忍

  • 数据局部性

  • 截止期限

控制器

  • 控制器是业务流程背后的大脑。

  • 他们负责在节点,容器或者端点出现故障时进行通知并做出响应

  • 在这种情况下,控制器决定提起新容器

控制器运行库 Controller Runtime

它是用于运行容器的基础软件。
在我们的案例中,我们将使用Docker作为基础容器,但还有其他选择,例如:

  • Docker(通过CRI垫片)

  • rkt(将直接集成替换为Rktlet)

  • CRI-O

  • Frakti(Hypervisor上的Kubernetes,以前是Hypernetes)

  • rktlet(rkt的CRI实现)

  • CRI容器

主要的设计策略是,Kubernetes本身应与特定的运行时完全脱钩。
容器运行时接口(CRI)启用它。

kubelet

它是在群集中每个节点上运行的代理。
代理负责确保容器按预期在节点上运行。
其中包括以下内容:

  • 接收吊舱规格

  • 从API服务器下载pod机密

  • 安装量

  • 运行pod的容器(通过配置的运行时)

  • 报告节点和每个吊舱的状态

  • 运行容器启动,活动性和就绪性探针

Kube代理kube-proxy

  • Kube-proxy在每个节点上进行低级网络内务处理

  • 容器在服务器节点上运行,但是它们在统一网络设置中运行时彼此交互。

  • 尽管容器在不同的节点上运行,但kube-proxy使容器能够进行通信。

  • 它在本地反映了Kubernetes服务,并且可以执行TCP和UDP转发。

  • 它通过环境变量或者DNS查找群集IP。