ヘルムのために地獄に入る方法、しかしストローをつかむ

-疲れたヒップスターは真実を言う。



私たち全員(つまり、私)は、最終的にいくつかの問題を他の問題に置き換えるために、新しく輝かしいものすべてを本番環境にドラッグするのが大好きです。 この物語は私たち(つまり私)に捧げられています。



残りのテキストを理解して許すには、ユーザーレベルでKubernetesを操作する方法の表面的な知識と、 Helmについてのいくつかの噂が必要になります。



まず抽象化してから、誰かがこれに対処できるようにします。 私たちがスムージー、電動スクーター、Kubernetesの世界でコロンバスのような存在であると想像してください。 私たちの人々は、その小さな無限の州の1つで人口過密のヨーロッパの老女で混雑しており、クロンコプターのクランチにkronjobを使用した展開を毎日展開しています。 しかし、天文学者はすでに地平線の疑わしい曲率の説明を見つけました。 そして、まさに私たちが時代の選ばれたヴァンであるという感覚があります。 (しかし、だれも尋ねませんでした。)そして、そこのどこか、半円形の海を越えて-インドへの最短の道! 無限のオープンスペース、日常の負担からの解放、多くの無料の香辛料。 私たちの人々をそこに連れて行き、最後に彼らを解放するだけです! 私たちの目の前に海を広げることは、私たちがこのように素晴らしかったとしても大きすぎる。 したがって、船を建造し、展開、kronjob、およびその他の悪魔を詰め込み、帆の代わりにサービスを上げて、そこの光の中に舵を取る必要があります。 操縦するには、ヘルム、つまりヘルムが必要です。 彼はヘルメットです。 ヘルメットがあれば、何が待ち受けているかを前もって知っていれば間違いなく便利です。 しかし、実権はあります。 船の建造は簡単ではないので、助けが必要ですが、私たちのスタッフはいつも非常に役に立たないもので忙しくしています。 したがって、以前と同様に必要です。 私たちはゆっくりとスタートし、小さなボートを作り、インドへrowぎ、広大な広がりを自分の目で見て、1つのスパイスを取り、泳ぎ、人々に見せます。 人々はそれを好み、彼らは私たちの努力を祝福します。 その後、素晴らしい結果を準備し、構成を整え、すでに多くの船を建造します。 人々は健康で、興味があります。 私たちは、示し、伝え、啓発し、約束し、約束し、約束します...より多くの船-より多くの関心。 誰かが参加し、助けます。 このすべてがアイドル状態にならないように、私たちは近くのステージで泳いで、まだスパイスはありません、そこに住むことは不可能ですが、観光客はそれを好みます。 そして今、数週間/数ヶ月/最優秀年/袖の後に彼は、あの日、到着しました! 艦隊を解放し、秘蔵のテラ・インコグニータを征服する時が来ました。 魂に恐怖を感じて、私たちは人々をインドに航海している、そしてそこでアメリカ、それは下がった そして、すべてが非常に似ているように見えますが、これは予感です...もちろん、私たちの人々はすぐにそれを味わいます(笑) しかし、あちこちで、まるで地球を通り抜けているかのように、何かが定期的に消えます。 その床は消え、ココナッツは出産しません。 そして、私たちは、待って、待って、まだ準備ができていないので、1日だけ与えてください ...」 しかし、私たちは慎重に目を細めると、そこの各茂みの前で、突然トマホークのインディアンが現れて、不気味にまたは何かに見えます...そして、寒さが内側の神経節を通り抜けます。 そして人々は:-「それは何ですか? そして私の床はどこにあるのでしょうか? もちろん、私があなたを40年間誤解させたわけではなく、誰もあなたを埋葬するつもりはありませんが、それは緊急です、*****、周波数を構築する必要があります!!!!!!”そして” 、もちろん、いつものように。



それは、純粋なKubernetesからHelmに実稼働中の特定の数のサービスを移してから、それに出くわしたときの気持ちです。



さて、最後に、約束された節約のstraw。 まず、ライトバージョンですが、上記のナンセンスの説明があります。 デモシナリオは次のとおりです。



  1. プロジェクトのチャートを拡大しているとしましょう:1.5。 Helmと初めて、そしてそれ以前はKubernetesだけでした。
  2. その後、リリースにバグがあることがわかりましたが、バージョン1.4ではそうではありませんでした。 そして、ロールバックする必要がありますが、彼女とヘルムにもチャートはありませんでした。 したがって、私は昔ながらの方法でそれを行うことにしました: kubectl set image deployment/project project=registry.project.com/project:1.4 --record



    。 このため、および一緒にデプロイされた他のサービスのバンドル用。
  3. バグは、このサービスではなく、隣のサービスにあったことが判明したため、これですべてが正常になり、1.5が返されます。 さて、 helm upgrade --install



    を呼び出すと、大きな驚きが待っています( 詳細 ):画像はまだ1.4から、ラベルは1.5からです。 そしてHelmは、すべてが正常であることを示し、実際には1.5がデプロイされ、ポッドでさえ再起動されました(CIビルドは緑色です)。


これを避ける方法は? デプロイされたHelm Chartの上にある純粋なkubectlコマンドでHelmによって制御されるK8sリソースに変更を加えた場合、kubectlコマンドでこれらの変更もキャンセルする必要があります。 Helmは新しいチャートを展開できます。 しかし、彼は新しいチャートを以前のチャートと比較しますが、リソースの現在の状態とは比較しません。 また、画像を編集した場合、Chartの将来のバージョンには別の画像が含まれる可能性があり、すべて問題ありません。 しかし、環境変数を編集した場合、または引数を開始した場合など、新しいバージョンのChartは以前のものとほとんど変わらない可能性があります。 また、更新後も手動での変更は保持されます。



そして、手始めに、そのような予測不可能な状態に同意できない人のための節約ストローの重いバージョン



新しい技術は新しい悲しみの源です。



All Articles