广告

Kubernetes容器编排入门指南

  • 浏览(1,077)
  • 评论(0)
  • 译者:k8s

容器编排是指用于自动化、管理和调度由单个容器定义的工作负载的工具和平台。这个领域有很多参与者,包括Hashicorp的Nomad、Apache Mesos、Amazon的ECS,还有别忘了Google自己开发的Borg项目(Kubernetes就是从这个项目演变而来的)。每种技术都有优缺点,但Kubernetes的日益流行和强大的社区支持表明,Kubernetes目前是容器编排之王。             


Kubernetes在使用开源软件时具有明显的优势。作为一个开源平台,它与云无关,在它之上构建其他开源软件是有意义的。它还拥有超过40000名贡献者,而且由于许多开发人员已经熟悉Kubernetes,因此用户更容易集成在K8s之上构建的开源解决方案。      

       

把Kubernetes分解成模块             

分解Kubernetes的最简单方法是了解容器编排器的核心概念。容器用作基本的工作构建块,然后在彼此之上构建组件以将系统连接在一起。

             

组件有两种核心类型:工作负载管理器(托管和运行容器的方法)、集群管理器(代表集群做出决策的全局方法)。             

在Kubernetes中,这些角色由工作节点和管理工作(即Kubernetes组件)的控制平面完成。             

管理工作负载              

Kubernetes工作节点有一个嵌套的组件层。在底层是容器本身。             

从技术上讲,容器运行在pods中,pods是Kubernetes集群中的基本对象类型。以下是它们之间的关系:             

Pod:Pod定义应用程序的逻辑单元。它可以包含一个或多个容器,每个Pod部署到一个节点上。             

节点:这是作为集群中工作机的虚拟机;pods在节点上运行。             

集群:由工作节点组成,由控制平面管理。    

       

每个节点运行一个名为kublet的代理(用于在pod中运行容器),并运行一个kube代理(用于管理网络规则)。             

管理集群              

工作节点管理容器,Kubernetes控制平面对集群进行全局决策。             

控制平面由几个基本组件组成:             

内存存储(etcd):这是所有集群数据的后端存储。虽然可以使用不同的备份存储运行Kubernetes集群,但etcd(一个开源的分布式键值存储)是默认的。             


调度器(kube调度器):调度器负责将新创建的pod分配给适当的节点。             

API前端(kube-apiserver):这是一个网关,开发人员可以通过它与Kubernetes交互,以部署服务、获取指标、检查日志等。             

控制器管理器(kube Controller manager):监控集群并进行必要的更改,以使集群保持在所需的状态,例如扩展节点、保持每个复制控制器的正确pod数以及创建新的命名空间。

             

控制平面做出决策以确保集群的正常运行,并将这些决策抽象出来,这样开发人员就不必担心它们了。它的功能非常复杂,系统用户需要了解的是控制平面的逻辑约束,而不必过于纠结于细节。             

使用控制器和模板              

集群的组件决定了集群如何管理自己,但是开发人员或(人工)运维人员怎么告诉集群如何运行软件?这就是控制器和模板的来源。             

控制器编排pod,K8s对于不同的用例有不同类型的控制器。但关键的是Jobs(用于运行到完成的一次性作业),以及ReplicaSets(用于运行指定的一组提供服务的相同pod)。            

与Kubernetes中的其他概念一样,这些概念构成了更复杂系统的构建模块,允许开发人员运行弹性服务。我们鼓励你使用Deployments,而不是直接使用ReplicaSets

Deployments代表用户管理ReplicaSets并允许滚动更新。Kubernetes Deployments确保只有一些pod在更新时关闭,从而允许零停机部署。同样,CronJobs管理Jobs并用于运行调度好的和重复的进程。K8s的许多层允许更好的定制,但是Cronjob和Deployments足以满足大多数用例。             

一旦知道要选择哪个控制器来运行服务,就需要使用模板配置它。             

模板解析              

Kubernetes模板是一个YAML文件,它定义了运行容器的参数。与任何一种配置即代码一样,它有自己的特定格式和要求,需要学习很多东西。所幸的是,你需要提供的信息与针对任何容器编排器运行代码时所需的信息相同:             

——告诉它应用程序的名称              

——告诉它在哪里查找容器的镜像(通常称为容器注册表)              

——告诉它要运行多少个实例(ReplicaSets的数量)              

配置的灵活性是Kubernetes的众多优点之一。使用不同的资源和模板,还可以提供有关以下集群信息:环境变量、秘密的位置、应挂载以供容器使用的任何数据卷、每个容器或pod允许使用多少CPU和内存、容器应运行的特定命令等。             

把这一切结合起来              

结合来自不同资源的模板,用户可以在Kubernetes中互操作组件,并根据它们的需要进行自定义。             

在一个更大的生态系统中,开发人员利用Jobs、Services和Deployments(带有ConfigMaps和Secrets),生成需要在部署过程中精心编排的应用程序。             

管理这些步骤可以手动完成,也可以使用一个常用的包管理选项来完成。虽然完全可以根据Kubernetes API进行自己的部署,但打包配置通常是一个好主意,特别是如果你要发布的开源软件可能是由其他人部署和管理的。             

Kubernetes选择的打包管理器是Helm。它允许你打包自己的软件,以便在Kubernetes集群上轻松安装。             

其实并不难             

位于容器顶部的许多层和扩展可能使容器编排器难以理解。但一旦你把它们分解,搞清楚它们是如何相互作用的,其实并不复杂。就像一个真正的管弦乐队一样,你欣赏每一种乐器,喜欢它们的合奏。 

           

原文链接:

https://opensource.com/article/20/6/container-orchestration

  • 分享到:
  • icon
  • icon
  • icon
  • icon
箭头