我使用了两个配置Map-一个用于安装，一个用于卸载/删除，并在删除之前触发操作，我在卸载daemonsetannotations中定义了helm钩子。下面是用YAML编写的卸载守护进程的代码
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: delete-pack
namespace: mynamespace
labels:
app: <ex>
chart: <ex>
annotations:
"helm.sh/hook": pre-delete
"helm.sh/hook-weight": "-10"
"helm.sh/hook-delete-policy": hook-succeeded,before-hook-creation,hook-failed
spec:
selector:
matchLabels:
app: <ex>字符串
yaml文件的其余部分是定义装载卷等的常规模板。当运行install命令时，configmaps会在命名空间中注册，当使用kubectl description configmaps -n mynapest检查命名空间时，对于delete-packconfigmap，输出如下：
Name: delete-pack
Labels: app=sample
chart=sample
Annotations: meta.helm.sh/release-name: sample型
钩子定义不会被加载，因此，在运行delete时，configmaps被删除，钩子终止时错误如下：
configmap "delete-pack" not found型
并且从命名空间中清除配置Map。hook变成了一个orphonedPod，并且在不执行pre-delete action的情况下被删除。
我发现原因是注解没有与配置Map名称沿着加载到命名空间中。什么原因导致舵钩不注册？Kubernetes安装中是否存在根本性错误？
你能告诉我任何进一步的调试步骤吗？
更新
delete-pack的Configmap没有标注。但是当添加时，delete-pack根本不会在名称空间的configmap中注册。（即）
Name: pack
Labels: app=sample
chart=sample
Annotations: meta.helm.sh/release-name: sample
<delete-pack data absent>型
1条答案
按热度按时间pxq42qpu1#
Helm挂钩的主要设计点是运行Jobs。您可以使用它们来加载您的作业所需的内容，如ServiceAccounts和ConfigMaps。使用它们来加载DaemonSet并不能很好地工作，尤其是在删除前的挂钩中。
Helm hook documentation注意到：
如果资源是
Job或Pod类型，Helm将等待，直到它成功运行完成。[...]对于所有其他类型，只要Kubernetes将资源标记为已加载（已添加或已更新），该资源就被认为“就绪”。在您的设置中，您有一个删除前的DaemonSet。这不是一个Job或一个裸Pod，因此Helm将DaemonSet定义发送给Kubernetes;完成后，可能在创建任何单独的Pod之前，Helm会发送删除图表中所有其他内容的请求。
这就是ConfigMap上的挂接注解的重要之处。如果ConfigMap也被注解为删除前挂钩，则它不会作为
helm install主内容的一部分进行安装，但会在DaemonSet安装时加载。如果不是，则会在将DaemonSet发送到群集后立即卸载它。您可能遇到的另一个挑战是
helm.sh/hook-delete-policy: hook-succeeded注解。对于长时间运行的工作负载资源，“successed”（成功）的含义并没有明确的文档记录。如果“successed”只是表示“已提交到群集且未出现错误”，则可能会导致发送DaemonSet，然后立即将其删除。我在这里唯一的具体建议是制作钩子可以使用的ConfigMap的第二个副本。我可以想象编写一个专用的DaemonSet，它在大多数情况下都处于空闲状态，但在收到SIGTERM时会进行清理工作，然后可以作为一个普通的DaemonSet运行，而不是一个Helm钩子。这个用例对我来说似乎很不寻常，尤其是关于需要在主机上操作软件的评论，因为Kubernetes中的所有内容通常都在一个容器中运行，根本看不到或影响主机文件系统。