根据不同的环境，自动生成适应Kubernetes的配置参数

2 年 ago
宇, 华
2 minutes

首先

作为Kubernetes/Openshift的模板引擎，我试用了Openshift的模板功能，并将结果作为输出留下。如果其他人也在做类似的尝试，希望能得到一些好的方法和建议。

关于Kubernetes中的声明性配置

「宣言式描述的配置」是Kubernetes/Openshift的最重要功能（我个人的观点）。

「宣言的な記述」とは、システムがアプリケーションを稼働させるための理想的な形態を説明することであり、「宣言的な記述による設定」は、それ自体でその理想的な形態を実現できるということです。Kubernetes/Openshiftでは、コンテナだけでなく、ストレージやネットワーク、シークレットやレジストリなど、アプリケーションの稼働に必要なすべての構成を、「宣言的な記述による設定」として管理することができます。

迄今为止

传统上，通过以下工具来实现在云服务及其上层操作系统和中间件中的声明式配置和构建。通过使用工具进行声明式描述，将 IT 基础设施作为代码进行构建和管理的思维被称为 “基础设施即代码”（Infrastructure as Code）。

    • クラウドサービスに対して … AWS CFn, Azure ARM Template, Terraform

OS・ミドルウェアに対して … ChefやAnsibleなどの構成管理ツール

一方面，由于以下情况，理想的申明性代码无法写的场景也是存在的事实。

    • ツールの仕様がしょぼい、機能が足りない

 

    • そもそもクラウドサービスやOS・ミドルウェアが宣言的な記述での設定を想定して作られていない

 

    手作業前提の手順をそのまま無理やり宣言的なコードで記述しようとしている

结果，我不小心创造出了”基础设施即代码疲劳”这个词。

    Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する

从现在开始

一方面，Kubernetes被称为基础设施即代码（Infrastructure as Code Native）的软件，它通过实现一个称为Reconciliation Loop（突合循环）的功能来比对资源的期望状态和当前状态，并自动填充差异。这样一来，传统上通过Terraform或Chef进行的声明式配置变得更加简单、强大和实用。

Kubernetes/Openshift中具有声明性描述的配置文件被称为清单。在Kubernetes/Openshift中，可以将容器本身以及存储、网络、机密、注册表等用于应用程序运行所需的配置全部作为”声明性描述的设置”来进行管理。

另外，一般情况下，manifest文件会使用YAML格式进行描述。YAML格式是一种纯文本格式，非常适合使用Git进行版本控制。

因此，在Kubernetes / Openshift上运营应用程序和系统时，通过Git进行清单管理非常重要。通过Git进行清单管理基本上就是管理Kubernetes / Openshift的Git。我们在过去和将来的运营中需要十分注意，以确保不破坏上述Kubernetes / Openshift的优势。

为什么需要模板引擎

在考虑以Git（Github）为中心的Kubernetes/Openshift运维时，基本的思考方式如下：

    1. 在开发环境中开发和测试容器映像和清单。

 

    1. 将其推送到Git存储库的dev分支上。

从dev分支创建Pull Request至prod分支。
合并后，在生产环境中应用清单。

然而，在现实世界中，事情往往不会如此顺利。在开发环境完成开发和测试后，当尝试将其应用到生产环境时，会遇到各种不便之处。

    • Dev環境とProd環境でパラメータを変えたい（からマニフェストを修正しないといけない）

 

    • そもそも権限分離の関係で、namespaceが違う（からマニフェストを修正しないといけない）

 

    もっというとコンテナレジストリも違う（からマニフェストを修正しないといけない）

在应用到生产环境时，手动编辑经过开发环境测试的清单文件后再进行应用，这不符合我们应该要追求的方式。所谓的“运维避免”只会带来悲剧。解决上述限制的机制建设非常重要。

为了解决上述问题，一种方法是利用根据参数生成manifest的模板引擎。以下是一些常用的作为manifest模板引擎的代表性选项。

    1. Helm

 

    1. 自定义

 

    Openshift 模板功能

总结来说，这次我在寻找用于Red Hat Openshift的模板引擎，所以选择了使用3. Openshift模板功能。

舵

Helm（公式）是用于管理预先配置的Kubernetes资源包Helm Charts的工具。虽然它可以生成清单，但由于功能过于复杂，我们决定先暂缓使用。

自定义化 huà)

Kustomize是针对Kubernetes的清单管理工具（官方Github）。它与Kubernetes的配置命令kubectl集成，并可以通过kubectl进行使用。

然而，由于我作为IBM Cloud的Openshift3.11用户找到了以下描述，我决定放弃采用。

    Kustomize を使用して、複数環境で再利用するアプリを 4.3 クラスターでパッケージ化する

请注意：在运行3.11版本的OpenShift集群中，不支持使用Kustomize。

验证 Openshift 模板功能

我会立即尝试使用Openshift的模板功能。从命令的角度来看，由于已经整合到Openshift的oc命令中，所以需要准备两个东西：模板文件和配置值文件。

    第10章 TEMPLATES (テンプレート)

模板文件

根据手头的Network LoadBalancer的清单创建模板。实际的清单将从objects:到parameters:。变量化想要替换的参数，例如”${PRIVATE_VLANID}”。模板文件可以放在任何一个易于理解的目录中。

apiVersion: v1
kind: Template
metadata:
  name: nlb-template
  annotations:
    description: "NLB template for cluster"
    tags: "sample-tag"
objects:
- apiVersion: v1
  kind: Service
  metadata:
    name: nlb
    annotations:
      service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: private
      service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "${PRIVATE_VLANID}"
  spec:
    type: LoadBalancer
    selector:
      app: sampleapp
    ports:
    - name: port01
      protocol: TCP
      port: 12345
    - name: port02
      protocol: TCP
      port: 12346
    loadBalancerIP: ${LBIP}
parameters:
- description: private_vlanid
  displayName: private_vlanid
  name: PRIVATE_VLANID
  required: true
- description: LoadBalancer_IP
  displayName: LoadBalancer_IP
  name: LBIP
  required: true

参数文件

创建一个包含实际参数值的参数文件。创建用于生产环境和开发环境的参数文件，并与模板文件一起进行版本管理。参数文件可以放置在任何易于理解的目录中。

PRIVATE_VLANID=010001
LBIP=10.0.0.1

PRIVATE_VLANID=000001
LBIP=192.168.0.1

产生

我会尽快生成一个简要说明书。首先，这是针对开发环境而言的。

$ oc process –本地 -f 模板/nlb_template.yaml –param-file 构建/dev –output yaml

apiVersion: v1
items:
- apiVersion: v1
  kind: Service
  metadata:
    annotations:
      service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: private
      service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "010001"
    name: nlb
  spec:
    loadBalancerIP: 10.0.0.1
    ports:
    - name: port01
      port: 12345
      protocol: TCP
    - name: port02
      port: 12346
      protocol: TCP
    selector:
      app: sampleapp
    type: LoadBalancer
kind: List
metadata: {}

我可以看到参数化的部分已被替换为实际的值。

接下来，生成用于生产环境的清单文件。

$ oc用模板/nlb_template.yaml -f –local –param-file构建/prod –output yaml 进行过程处理

apiVersion: v1
items:
- apiVersion: v1
  kind: Service
  metadata:
    annotations:
      service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: private
      service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "000001"
    name: nlb
  spec:
    loadBalancerIP: 192.168.0.1
    ports:
    - name: port01
      port: 12345
      protocol: TCP
    - name: port02
      port: 12346
      protocol: TCP
    selector:
      app: sampleapp
    type: LoadBalancer
kind: List
metadata: {}

通过参数文件的值可以确定生成了用于生产环境的清单。

此外，您还可以通过以下方式直接 oc apply 生成的清单。实际上，您可以将此命令包装在Shell脚本中，以便一次生成和应用，或者将其注册到 CI 环境中。

使用本地的模板文件`template/nlb_template.yaml`，根据参数文件`build/prod`在OpenShift中进行处理，并应用。

总结

在解释为什么需要模板引擎的情况下，我们使用Openshift的模板功能来生成用于生产环境和开发环境的清单模板。

若要考虑实际操作Kubernetes/Openshift，很多时候不会如理想般顺利。像以往一样“在运营中避免”或“工匠手动处理”这样做，将破坏Kubernetes/Openshift的优势。我们希望通过共享技巧和工具，致力于更轻松的运维。

参考-
只需要一个选项，用中文本地化地改写以下内容：

在实践云原生DevOps的过程中，使用《Kubernetes操作规范指南书》，在开始“在Kubernetes上操作”之前，重点要考虑在生产环境中使用Kubernetes的要点。

可能会将feature分支推送到dev分支，并可能会进行插入Pull Request。
✖
广告
将在 10 秒后关闭
bannerAds