您好,欢迎来到12图资源库!分享精神,快乐你我!我们只是素材的搬运工!!
  • 首 页
  • 当前位置:首页 > 开发 > WEB开发 >
    选型必看:Kubernetes 运用顺序部署工具应该选哪些?
    时间:2020-11-25 21:01 来源:网络整理 作者:网络 浏览:收藏 挑错 推荐 打印

    选型必看:Kubernetes 运用顺序部署工具应该选哪些?

    将运用顺序部署到 Kubernetes 十分复杂,只需求用 yaml 或 json 编写一些资源定义并将它们运用到 kubectl 中就可以了,但要完成配置自动化就相对复杂了。

    在运用顺序部署中,一个比较盛行的做法是将继续部署和 GitOps 结合运用C拦畚对源代码停止更改后,资源都会自动部署。假设想要运用 GitOps 将运用顺序部署到 Kubernetes,需求阅历以下进程:

    容器映像构建, 将源代码和本地依赖关系构建到容器映像中。

    资源模板, 为环境定制部署资源的资源模板。

    包管理, 将多个资源捆绑到版本发布中,并管理包依赖关系。

    继续部署, 通常经过一系列操作和步骤,对环境停止更改。

    命令式部署, 以编程方式管理复杂的效劳生命周期,并增加手动或复杂的脚本化步骤。

    自动缩放, 依据资源运用状况和消耗状况,自动缩放来管理运用顺序的照应和资源分配。

    在本文中,我引见了 Kubernetes 运用顺序生命周期管理的各个阶段能够会运用的一些工具(主流非主流的都有)。由于很难客观地判别工具的盛行性和成熟度, 因此我对这些工具停止了注释,阐明了哪些大型公司对这些项目停止了投资,供你参考判别。不过请记住,大公司对一个项目通常能够会做多个竞争性投资,因此,仅仅由于项目拥有一位知名的投资者,并不能得出它可以长期生活和开展的结论。

    希望此列表可以在你寻觅运用顺序部署成绩处置方案时提供一些协助。

    1. 容器镜像构建

    Moby /buildkit (Docker) ——用于将源代码转换为构建工件的工具包。

    kaniko(Google)—— 在容器或 Kubernetes 集群中从 Dockerfile 构建容器映像的工具。

    img(Jess Frazelle) ——一个独立的,没有守护进程,非特权形式的 Dockerfile 和 OCI 兼容的容器映像构建器。

    buildah (IBM/Red Hat)——用于构建开放式容器方案 (OCI) 容器映像的工具。

    Source-To-Image(IBM/Red Hat)——用于从源构建工件并注入容器映像的工具。

    Tanzu Build Service/kpack /pack (VMware/Pivotal) ——运用 Cloud Native Buildpacks 构建运用顺序的 CLI 和效劳。

    Carvel /kbld (VMware/Pivotal)——用于构建映像并将其推入开发和部署任务流的效劳。

    Google Cloud Buildpacks(Google)——为运转在谷歌云的容器平台而设计的构建器和构建包。

    Makisu (Uber) ——快速而灵敏的 Docker 镜像构建工具,可以在 Mesos 和 Kubernetes 等非特权的容器环境中任务。

    2. 资源模板

    Helm(Microsoft, Google) ——Kubernetes 包管理器。

    Kustomize(Google, Apple)——用于定制原始的、无模板的 YAML 文件的 CLI,使原始的 YAML 保持原样并保持可用。

    Carvel /ytt (VMware/Pivotal)——基于 YAML 结构的 YAML 模板工具。

    jsonnet/go-jsonnet(Google) ——JSON 模板言语。

    gomplate(Dave Henderson) ——用于 golang 模板渲染的 CLI,支持本地和远程数据源。

    Mustache (Github) ——与框架有关的 JSON 模板引擎。

    3. 包管理

    Helm(Microsoft, Google) ——一个 Kubernetes 包管理器。

    Cloud Native Application Bundles (CNAB)/Porter/Duffle(Microsoft/Deis, Docker)——这是一个用于管理云有关的散布式运用顺序的包格式标准、打包器和安装顺序。

    4. 继续部署

    Spinnaker(Netflix, Google) ——多云继续交付平台,用于快速高质量迭代发布软件变更。

    Terraform Kubernetes Provider (Hashicorp) ——一个 Terraform 插件,支持 Kubernetes 资源的残缺生命周期管理。

    Concourse (VMware/Pivotal)——一个基于容器的延续事务处置顺序,用 Go 和 Elm 编写。

    JenkinsX(CloudBees)—— 用于 Kubernetes 的自动化 CI / CD,提供运用 Tekton、Knative、Lighthouse、Skaffold 和 Helm 的 pull 央求预览环境

    Argo CD(Intuit)—— 用于 Kubernetes 的高效 GitOps 继续交付工具。

    Tekton/Tekton Pipelines(Google) ——一个 Kubernetes 控制器, 提供 CI / CD 样式的管道资源。

    Cloud Build(Google)——在谷歌云平台基础设备上执行构建的效劳。

    Skaffold(Google)——促进 Kubernetes 运用顺序继续开发的 CLI。

    Azure DevOps/Azure Pipelines(Microsoft) ——一种云效劳,它可以自动构建和测试项目的代码,并将其提供应其他用户。

    Brigade(Microsoft) —— Kubernetes 的基于事情的脚本。

    Habitat/habitat-operator(Chef) ——Kubernetes 控制器,在 Kubernetes 上运转和管理 Habitat 效劳。

    gitkube(Hasura) ——运用 git push 在 Kubernetes 上构建和部署 Docker 镜像的工具。

    5. 命令式部署

    Kubebuilder(CNCF, Google, Apple, IBM/Red Hat) ——用于运用 CRD 构建 Kubernetes API(以及控制器和操作符) 的 SDK。

    Operator Framework/Operator SDK(IBM/Red Hat/CoreOS) ——用于构建 Kubernetes 运用顺序操作符的 SDK。

    KUDO(D2IQ) ——运用声明式办法构建消费级 Kubernetes 操作符的框架。

    Pulumi(Pulumi)——可以作为代码 SDK 的基础设备,用于在各种云上创立和部署运用容器、无效劳器功用、托管效劳和基础架构的云软件。

    Carvel/kapp/kapp-controller(VMware/Pivotal)——CLI 和 Kubernetes 控制器,用于安装运用顺序 CRD 所描画的配置 (helm 图表, ytt 模板,yaml 文件)。

    Isopod(Cruise)——在没有 YAML 的状况下,用于 Kubernetes 资源配置的表达性 DSL 和框架。

    6. 自动缩放

    Horizontal Pod Autoscaler(built-in)—— Kubernetes 控制器,它依据配置的目的自动伸缩复制控制器、部署、复制集或有形状集中的 Pods 数量。

    Vertical Pod Autoscaler(Google)——一组 Kubernetes 组件,自动调整运转在 Kubernetes 集群中的 pods 央求的 CPU 和内存数量。

    Addon Resizer(Google) ——垂直 Pod 自动调用器的简化版本,它依据 Kubernetes 集群中的节点数量修正部署的资源央求。

    KEDA(Microsoft)——一个基于 kubernet 的事情驱动的自动缩放组件。

    Watermark Pod Autoscaler Controller(DataDog) ——扩展了 Horizontal Pod Autoscaler (HPA) 的自定义控制器。

    Pangolin(Damian Peckett)—— 针对 Kubernetes 的一个增强的 Horizontal Pod Autoscaler,它基于 Prometheus 目的来扩展部署,运用各种高度可配置的控制策略。

    Predictive Horizontal Pod Autoscaler(IBM) —— 自定义 Pod Autoscaler,相似于 Horizontal Pod Autoscaler,但是添加了预测元素。

    Horizontal Pod Autoscaler Operator(Banzai Cloud)——Kubernetes 控制器,它监视部署或形状集,并基于 autoscale 注释自动创立 Horizontal Pod Autoscaler 资源。

    7. 写在最后

    正如 DevOps 倡导者宣扬的那样:这与工具有关,而与观念有关。没有一个工具能给你带来让你兴奋的全生命周期端到端管理体验,由于每种工具都有他们本人的工具组合,经过与脚本和集成代码配合完成任务。

    你可以找到可以很好地完成一件事情的工具,易于交流和扩展,也可以选择为你提供最大性价比的工具,让你更容易对项目停止管理,集成成本也更低,同时还拥有较好的端到端用户体验。以上的选择都没有什么错。

    (责任编辑:admin)