云原生知识星球
0%

解析Helm Char Release内容

发表于 更新于 分类于 阅读时长 ≈ 3 分钟

如果我们在集群中安装了Helm Chart，可能会想知道Release的存储位置。

背景知识

让我们从一些背景开始。安装一个简单的Nginx Helm Chart：

1
$ helm install --name my-release stable/nginx-ingress

现在，要获取已安装Helm的详细信息，可以使用四个命令。

helm ls

1
2
3
$ helm ls 
NAME        REVISION	UPDATED                 	STATUS  	
my-release  1      	    Wed Sep 12 07:41:48 2018	DEPLOYED

通常，我们要运行的第一个命令是helm ls。执行此操作是为了了解我们的集群中当前安装了哪些Helm Chart。无论它们是否失败，STATUS会展示出部署结果是成功还是失败。

helm get

一旦获得安装Chart的名称。下一步通常是尝试更详细地了解安装了什么。helm get命令可以为我们提供帮助。

1
2
3
4
5
6
7
8
9
10
11
12
13
$ helm get my-release
REVISION: 1
RELEASED: Thu Mar 23 15:59:14 2017
CHART: nginx-1.0
USER-SUPPLIED VALUES:
foo: bar

COMPUTED VALUES:
foo: bar
image: nginx
imagePullPolicy: IfNotPresent
ingress:
# **....**

helm status

如果我们遇到任何问题，并且希望获得Chart开发人员写下的一些说明。helm status可以通过呈现NOTES.txt文件来帮助我们。

1
2
3
4
5
6
$ helm status my-release
The nginx-ingress controller has been installed. 
Get the application URL by running these commands:
export NODE_IP=$(kubectl --namespace {{ .Release.Namespace }} get nodes -o jsonpath="{.items[0].status.addresses[1].address}")   
echo "Visit http://10.10.10.10:80 to access your application via HTTP."  
echo "Visit https://10.10.10.10:443 to access your application via HTTPS."

上面的Helm状态可以通过values.yaml或–set修改。这是从NOTES.txt呈现的帮助者文本。

helm history

最后，我们还可以获得Chart部署的修订历史记录。当运行helm upgrade命令时会更新版本。假设我们要使用override.yaml覆盖某些值。

1
2
3
4
5
$ helm upgrade --install my-release --values override.yaml --set foo=notbar nginx 
$ helm history my-release
REVISION    UPDATED                     STATUS      CHART           DESCRIPTION
1           Thu Mar 23 15:57:40 2020    SUPERSEDED  nginx-0.4.3 Install complete
2           Thu Mar 23 15:59:14 2020    DEPLOYED    nginx-0.4.3 Upgrade complete

所有这些信息都存储在哪里？

  • Helm v2版本，默认位置在configmap中：

    1
    2
    3
    4
    $ kubectl get configmap -n kube-system -l "OWNER=TILLER"
    NAME                     DATA      AGE
    my-release.v1          1         7m
    my-release.v2          1         6m

  • Helm v3版本，默认位置在secrets中。强烈建议这样做，因为这些数据包含许多有关我们部署的信息：

    1
    2
    3
    4
    5
    $ kubectl get secrets -n kube-system
    NAME                     DATA      AGE
    my-release.v1          1         7m
    my-release.v2          1         6m
    default-token-43hfuds  1         1d

解析Configmap内容

步骤1. 获取Configmap数据：

1
$ kubectl get configmap -n kube-system my-release.v1 -o=jsonpath='{.data.release}' > release-encoded

步骤2. 确保编码后的Release包含如下字符串：

1
2
H4sIAAAAAAAC/+w6TY8cS.....
# you should see a long block of string like above

步骤3. 解析数据：

1
cat release-encoded | base64 -d | gzip -cd > release-decoded

步骤4. 查看数据：

1
2
3
4
cat release-decoded
# you should see a whole bunch of data for the chart similar to above when you did helm get.
# but also this data contains a lot more like. the actual template. Value rendered.. etc... 
# try it :) i already gave you the commands 🤠⽕😁🏃🏼‍

将Chart存储在configmaps中的问题在于，一旦黑客进入我们的集群，它就会成为黑客的金钥匙。将其存储为secrets可以提供某种保护（假设我们对机密信息进行了加密）。☸️

解析Secrets内容

步骤1. 解析指定版本的Release所有内容（Template内容依然是编码格式）：

1
kubectl get secret sh.helm.release.v1.my-release.v1 -o jsonpath="{ .data.release }" | base64 -d | gunzip -c | jq .

步骤2. 解析指定版本的Release中的Template内容：

1
kubectl get secret sh.helm.release.v1.my-release.v1 -o jsonpath="{ .data.release }" | base64 -d | gunzip -c | jq '.chart.templates[].data' | tr -d '"' | base64 -d

注：该方法同样适用于解析Configmap内容。

一些建议

还有一些保护tiller的方法，例如使用https连接。但是，按照设计，tiller仍然需要大量特权才能在我们的集群中运行。并且仍然违反最小特权原则。我的建议是尽快移至helm3。

Helm3完全删除了tiller，而是依靠本地计算机的身份验证在群集中工作。默认情况下，它还将Chart数据作为secrets存储在群集中。Helm2将在2020年12月停止提供安全修复程序。