🖕🏽 ⛑️ 👨‍👩‍👧‍👧 Kubernetes技巧与窍门：将集群资源移至Helm 2 🚬 👨🏾‍🚒 👬

当您不能仅仅使用Helm工具重新创建Kubernetes集群的资源时，可能会在战斗条件下获取它们。可以区分两个主要原因：

这将很简单-无论您是浮云还是裸机。
删除后，云中的服务可能会丢失，并且Kubernetes中关联的负载均衡器也会飞走。

在我们的案例中，在集成我们的Kubernetes运营商时，需要该解决方案来捕获有效的ingress-nginx 。

Helm所管理的资源不是由他创建的，这是绝对不可接受的。

“如果可以手动更改团队的发布资源，请准备好解决以下部分中描述的问题： [BUG]推出后，群集中发布资源的状态与所描述的Helm图不符 。” （摘自上一篇文章）

如前所述，Helm的工作原理如下：

每次安装（ helm install ， helm upgrade命令）Helm都会将生成的发行清单保存在存储后端中。默认情况下，使用ConfigMaps：对于发行版的每个修订版，都在运行Tiller的相同名称空间中创建ConfigMap。
再次推出（ helm upgrade命令）时，Helm将新生成的清单与ConfigMap中最新的DEPLOYED发行版的旧清单进行比较，并在Kubernetes中应用所得差异。

基于这些功能，我们得出的结论是，足以修补ConfigMap（存储后端版本）以进行提取，即采用集群中的现有资源。

耕作程序以以下格式引用ConfigMap： %RELEASE_NAME.v%REVISION 。要获取现有条目，必须运行命令kubectl get cm -l OWNER=TILLER --namespace kube-system （默认情况下，Tiller安装在名称空间kube-system否则，必须指定使用的那个）。

 $ kubectl get cm -l OWNER=TILLER -n kube-system NAME DATA AGE release_name_1.v618 1 5d release_name_1.v619 1 1d release_name_2.v1 1 2d release_name_2.v2 1 3d

每个ConfigMap都以以下格式显示：

 apiVersion: v1 data: release: H4sIAHEEd1wCA5WQwWrDMAyG734Kwc52mtvwtafdAh27FsURjaljG1kp5O3nNGGjhcJ21M/nT7+stVZvcEozO7LAFAgLnSNOdG4boSkHFCpNIb55R2bBKSjM/ou4+BQt3Fp19XGwcNoINZHggIJWAayaH6leJ/24oTIBewplpQEwZ3Ode+JIdanxqXkw/D4CGClMpoyNG5HlmdAH05rDC6WPRTC6p2Iv4AkjXmjQ/WLh04dArEomt9aVJVfHMcxFiD+6muTEsl+i74OF961FpZEvJN09HEXyHmdOklwK1X7s9my7eYdK7egk8b8/6M+HfwNgE0MSAgIAAA== kind: ConfigMap metadata: creationTimestamp: 2019-02-08T11:12:38Z labels: MODIFIED_AT: "1550488348" NAME: release_name_1 OWNER: TILLER STATUS: DEPLOYED VERSION: "618" name: release_name_1.v618 namespace: kube-system resourceVersion: "298818981" selfLink: /api/v1/namespaces/kube-system/configmaps/release_name_1.v618 uid: 71c3e6f3-2b92-11e9-9b3c-525400a97005 OU4 + BQt3Fp19XGwcNoINZHggIJWAayaH6leJ / 24oTIBewplpQEwZ3Ode + JIdanxqXkw / D4CGClMpoyNG5HlmdAH05rDC6WPRTC6p2Iv4AkjXmjQ / WLh04dArEomt9aVJVfHMcxFiD + 6muTEsl + i74OF961FpZEvJN09HEXyHmdOklwK1X7s9my7eYdK7egk8b8 / 6M + HfwNgE0MSAgIAAA == apiVersion: v1 data: release: H4sIAHEEd1wCA5WQwWrDMAyG734Kwc52mtvwtafdAh27FsURjaljG1kp5O3nNGGjhcJ21M/nT7+stVZvcEozO7LAFAgLnSNOdG4boSkHFCpNIb55R2bBKSjM/ou4+BQt3Fp19XGwcNoINZHggIJWAayaH6leJ/24oTIBewplpQEwZ3Ode+JIdanxqXkw/D4CGClMpoyNG5HlmdAH05rDC6WPRTC6p2Iv4AkjXmjQ/WLh04dArEomt9aVJVfHMcxFiD+6muTEsl+i74OF961FpZEvJN09HEXyHmdOklwK1X7s9my7eYdK7egk8b8/6M+HfwNgE0MSAgIAAA== kind: ConfigMap metadata: creationTimestamp: 2019-02-08T11:12:38Z labels: MODIFIED_AT: "1550488348" NAME: release_name_1 OWNER: TILLER STATUS: DEPLOYED VERSION: "618" name: release_name_1.v618 namespace: kube-system resourceVersion: "298818981" selfLink: /api/v1/namespaces/kube-system/configmaps/release_name_1.v618 uid: 71c3e6f3-2b92-11e9-9b3c-525400a97005

生成的清单以二进制形式存储（在上面的示例中，使用.data.release键），因此我们决定使用标准的Helm工具创建发布，但要使用特殊的存根（stub） ，稍后将其替换为所选资源的清单。

实作

解决方案算法如下：

我们正在准备一个manifest.yaml文件，其中包含要使用的资源清单（下面将对此进行更详细的讨论）。
我们创建一个图表，其中有一个带有临时ConfigMap的模板，因为没有资源，Helm无法创建发行版。
我们创建一个templates/stub.yaml ， templates/stub.yaml长度与manifest.yaml的字符数相等（在实验过程中，字节数必须匹配）。作为存根，应选择可复制的字符集，该字符集将在生成后保留并存储在存储后端中。为了简单明了，使用# ，即：
```
 {{ repeat ${manifest_file_length} "#" }} 
```
安装图表： helm install和helm upgrade --install 。

我们将manifest.yaml的资源manifest.yaml替换为manifest.yaml中在第一步中选择采用的资源manifest.yaml ：

 stub=$(printf '#%.0s' $(seq 1 ${manifest_file_length})) release_data=$(kubectl get -n ${tiller_namespace} cm/${release_name}.v1 -o json | jq .data.release -r) updated_release_data=$(echo ${release_data} | base64 -d | zcat | sed "s/${stub}/$(sed -z 's/\n/\\n/g' ${manifest_file_path} | sed -z 's/\//\\\//g')/" | gzip -9 | base64 -w0) kubectl patch -n ${tiller_namespace} cm/${release_name}.v1 -p '{"data":{"release":"'${updated_release_data}'"}}'

我们检查Tiller是否可用，并获取我们的更改。
删除临时ConfigMap（从第二步开始）。
此外，该版本的工作与常规版本没有什么不同。

具有上述实现方式的要点位于：

 $ ./script.sh Example: ./script.sh foo bar-prod manifest.yaml Usage: ./script.sh CHART_NAME RELEASE_NAME MANIFEST_FILE_TO_ADOPT [TILLER_NAMESPACE]

作为脚本的结果，创建了RELEASE_NAME的发行版。它与清单在MANIFEST_FILE_TO_ADOPT文件中描述的资源相关联。还生成了一个CHART_NAME图表，该图表可用于进一步特别伴随清单和发布。

在使用资源准备清单时，有必要删除Kubernetes使用的服务字段（这些是动态服务数据，因此在Helm中对它们进行版本控制是不正确的）。在理想的世界中，培训归结为一个命令： kubectl get RESOURCE -o yaml --export 。毕竟，文档说：

  --export=false: If true, use 'export' for the resources. Exported resources are stripped of cluster-specific information.

...但是，正如实践所示，-- --export选项仍然是--export ，因此将需要其他清单格式。在下面的service/release-name-habr中，必须删除creationTimestamp和selfLink 。

kubectl版本

 $ kubectl version Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.3", GitCommit:"721bfa751924da8d1680787490c54b9179b1fed0", GitTreeState:"clean", BuildDate:"2019-02-01T20:08:12Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.3", GitCommit:"721bfa751924da8d1680787490c54b9179b1fed0", GitTreeState:"clean", BuildDate:"2019-02-01T20:00:57Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}

kubectl获取服务/发布名称-habr -o yaml --export

 apiVersion: v1 kind: Service metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app.kubernetes.io/instance":"release-name","app.kubernetes.io/managed-by":"Tiller","app.kubernetes.io/name":"habr","helm.sh/chart":"habr-0.1.0"},"name":"release-name-habr","namespace":"default"},"spec":{"ports":[{"name":"http","port":80,"protocol":"TCP","targetPort":"http"}],"selector":{"app.kubernetes.io/instance":"release-name","app.kubernetes.io/name":"habr"},"type":"ClusterIP"}} creationTimestamp: null labels: app.kubernetes.io/instance: release-name app.kubernetes.io/managed-by: Tiller app.kubernetes.io/name: habr helm.sh/chart: habr-0.1.0 name: release-name-habr selfLink: /api/v1/namespaces/default/services/release-name-habr spec: ports: - name: http port: 80 protocol: TCP targetPort: http selector: app.kubernetes.io/instance: release-name app.kubernetes.io/name: habr sessionAffinity: None type: ClusterIP status: loadBalancer: {}

以下是使用脚本的示例。他们两个都演示了如何使用脚本来采用群集中的资源，并随后使用Helm工具将其删除。