release — 留在集群里的部署记忆

一句话总结

发布不是命令的记录，而是存储在群集中的状态，这个状态在每次修订时都会用一个秘密累积起来。

为什么需要这个？

kubectl apply如果发布的话，虽然可以知道“现在有什么挂着”，但不能知道“昨天有什么挂着”。如果出现问题要恢复的话，必须从某个地方找到之前的manifest，但那个地方通常是人的记忆或某人的笔记本电脑。

Helm解决了这个问题，说：“每次部署时，都会将该部署的整个快照留存在群集中”。剩下的不仅仅是渲染好的配置文件。那时使用的图表元数据、用户提供的值、状态、发布说明也会全部包含进去。所以撤销不是“找以前的文件”，而是“选择存储的版本”。

怎么行动

Helm 3中没有在群集中常驻的服务器组件。CLI通过kubeconfig直接与API服务器对话，因此Kubernetes RBAC可以直接应用。那么状态放在哪里呢——放在安装了版本的命名空间的Secret上。

项目	值
秘密名字	sh.helm.release.v1.<릴리스이름>.v<리비전번호>
秘密类型	helm.sh/release.v1
标签	owner=helm，name=<릴리스이름>，status=<상태>
内容	图表元数据、渲染的manifest、values、状态、笔记gzip压缩后base64编码

每次修订都会增加一个秘密。所以kubectl get secret -l owner=helm光看就看出那个名称空间的部署历史有多层。基本上保留最近10个--history-max调整为。

升级不仅仅是简单的覆盖。Helm 3 比较三件事——以前版本的配置文件、现在群集的实际状态，以及重新渲染的配置文件。这就是three-way strategic merge patch。多亏了这一点，有人kubectl识别直接操作的领域，不操作图表管理的不相关的领域，只选择变化的部分进行应用。

而且有两个一定要记住的性格。

**第一，失败的升级也会作为修订保留下来。**虽然渲染完成了，但如果API服务器拒绝的话，那个修订failed记录在状态中，实物保持原来的状态。在记录中留下失败不是事故，而是功能——为什么尝试了什么却失败了，会留在聚类中。

第二，回滚不是回溯，而是创建新的版本。如果用版本2回滚，号码不会回到2，而是会产生版本2的图表和用values计算的新的版本4。版本号总是向前走的。多亏了这种特性，“回滚后再次取消回滚”的事情也会完整地留在履历上。

查询价格的方法也有两条路。helm get values只有用户实际传递的值，-a(--all）后，会显示包括图表基本值在内的最终值。--revision N一起给的话可以查看特定版本的值。在应对障碍中，区分“这个设置是默认值还是谁输入的值”是这两个命令的区别。

在现场相遇的样子

**第一，停止的pending状态。**如果升级过程中进程崩溃，发布会pending-upgrade留下后，下一条命令会被拒绝。这时需要的不是用手擦去秘密，而是用最后一次成功版本倒退，整理状态。

第二，--atomic的两个面孔。--atomic银--wait包括在内，失败时会自动返回，所以对管道很好。但是如果自动返回的话，观察失败状态的机会就会消失。在需要观察原因的情况下，不会故意粘贴。

**第三，价格的漂移。**有人--set如果急忙增加复制次数超过了障碍，那么该值只存在于那个版本中。下次发布会悄悄地将其恢复。因此，临时插入的值必须反映在存储库的值文件中。

释放被堵住时打开的顺序

头盔在分发顺利的时候很方便，一旦偏差，就必须亲自检查状态。经常 有三样东西可以看。

**pending-upgrade被困在里面。**升级过程中CI死亡或超时 如果我，发布会保持在那样的状态，下次helm upgrade去“another operation is in 被拒绝为"progress"。确认没有实际进行的工作后，会撤销。

helm history myapp -n prod
helm rollback myapp <마지막 deployed 리비전> -n prod

--atomic科--wait做其他事情。--wait在银资源准备好之前 等待，--atomic如果等待失败，**会自动恢复。**在管道中 --atomic --timeout 10m最好一起使用。不然的话，只有一半才适用。 状态还剩。

勾子造成了僵局。pre-upgrade用勾捕来捕捉迁移，但那个捕捉 使用新版本的图像，该图像只有在升级完成后才能发布，因此在结构上永远不会 等待。在钩子上写已经有的图片，hook-delete-policy失败了 留下抓取的记录，以便查看日志。

annotations:
  "helm.sh/hook": pre-upgrade
  "helm.sh/hook-weight": "-5"
  "helm.sh/hook-delete-policy": before-hook-creation

确认价格从哪里来的。-f很多个和--set如果混合这两个，最终值是 很困惑。后面来的赢，--set比这个文件重。

helm get values myapp -n prod --all      # 실제로 쓰인 값(기본값 포함)
helm template . -f values-prod.yaml | kubectl diff -f -

CRD在升级时不会被更新。crds/目录的东西只有在安装时才可以 适用。上传了图表，但新字段不接受的话，就是这个位置。CRD需要单独适用。 做。

下次实习要做的事情

名称空间helm-lab发布于lab-app安装后创建版本1，增加复制次数创建版本2。然后故意放入API服务器拒绝的值，创建失败版本3，然后用版本2回滚，获得版本4。helm get values的-a一起和没有一起分别抽取并比较，直接确认了堆积在命名空间中的发布秘密后，制作生命周期报告。