非機能系要件をKubernetes上で実現すること
こんにちは、ソフトウェアエンジニアをやっている三つ永です。
こんにちは、ソフトウェアエンジニアの博多恵です。
ゆるテクは三つ永と博多恵が緩く技術の話をするポッドキャストです。よろしくお願いします。
よろしくお願いします。
はい、じゃあそんなわけで今日もお話をしていきたいなと思っておりますが、
今日のホストは私三つ永の方なので、私からちょっと話題を提供したいなと思います。
はい、お願いします。
ちょっと今日の話題はですね、
普段自分の業務に少し関連しているところで気づきというか、
調べたものがあったので、その話を博多恵さんとやろうかなと思ってます。
はい。
今日その業務に関連するって言ってるのが、私普段SREエンジニアとして
インフラの構築であったりとかDevOpsの実践をやってるんですけれども、
ちょうど最近、自分たちの運用しているサービスのインフラ環境のバージョンアップがあったんですよ。
クーバネティスのバージョンを上げたりとか、その他使っているOSS、ミドルウェアのバージョンを上げたりということですね。
バージョンアップがありまして、
基本私たちのプロダクトの場合はクーバネティスのバージョンアップが一番大きなトピックというかイベントになってくるんですけど、
ふと自分たちが運用している環境のポット数、コンテナを動かしているポット数の割合が
だいぶサービス例明記というか、サービス立ち上げたタイミングから比べると変わってきたなということに気づいて、
そういう話をちょっと調べたりもしたので、ぜひ博多家さんに共有したいなと思ってます。
いや、これ面白いですね。
面白いですかね。面白いといいんですけどね。
軽く共有をすると、私たちが今やっているプロダクトって基本的にマイクロサービスアーキテクチャを採用していて、
なので各アプリケーションのポットがあったりとか、サービスメッシュのポットがあったりとか、ロギングするためのポットがあったりとかいろいろポットがもともとあるんですけど、
サービスを開始した直後って、すべてのポット数とかを足しても、いいとこ30個ぐらいだったんですよ。
そのうちアプリケーションが冗長構成にもなって、レプリカセットで冗長構成にもなってたりするので、その30個のうちだいたい20個ぐらいが実アプリでした。
なので昔はクラスターのバージョンアップとかもそんな難しくないというか、心配せずバージョン上げてAPI直して動けば動いたねだったんですけど、
実はふと今回のバージョンアップが終わった時にポットの数を数え直したら、サービス開始時30個だったものが今ポット数が500個ぐらいになっててですね。
いい成長具合。
いい成長具合。すごいなって最初思ったんですけど、ただその500個のうち実サービスのポットって40個ぐらいしかないんですよ。
さっきがいくつって言ってましたっけ。
さっきが20個です。
ということは倍。
倍。しかも倍っていうのがマイクロサービスの種類が増えたかというとそういうわけではなくて、サービスの種類がたくさん増えたというよりは一つのサービスのレプリカ数が増えた。
その結果アプリケーションのポット数が増えたってだけなんですよ。
なのでサービス立ち上げの時から比べて圧倒的にミドルウェアとか非機能の部分を担保するためのポットが増えてる。
私たちで言うと500分の40だから9対1ぐらいになっちゃってるんですよ。
そうするとめちゃめちゃバージョンアップするときに大変だなっていうのがSREやってるメンバーと話してて出てきた話でちょっとだけ2人で振り返ってみてなんでこんなことになったんだろうみたいなことをちょっと振り返ってみました。
今2人で話してるときに見てるボードには書いてあるんですけど用っていう振り返り、やったこと、起こったこと、分かったことっていう振り返りベースで振り返ってみた結果2人から出てきた意見ってこんなことがありましたよっていうところでまずやったことなんですけど
なんでしょうKubernetesの環境を使って基本的にはサービスの運用をしてるんですけど何かロギングとかセキュリティとかメッセージングは非機能ではないかもしれないんですけどそういった非機能系の要件を何かプロダクトで出てきたときに基本自分たち全部Kubernetesの中に収めてるねってことにまず気づきましたと。
いわゆるクラウドを使っているけどそのクラウドで提供されているマネージドな機能とかを使うのではなくKubernetes上でってことですよね。
OSSのポッド数の増加
そうですそうです。
今、科学たけさんのお話で出てきたみたいにマネージドなものを使うのではなくっていうのがまさにそうで、なるべくOSS使っちゃったねっていうのがまずやったこと。
たぶんそのときOSSを使った背景って例えばまずこれを入れるにあたってプロトタイピングとしてOSSを使ってみて、じゃあより効果があったら商用とかマネージドに変えていきましょうっていう戦略もありましたし、あるいはシンプルに予算がないからOSSでやりましょうも確かにあったっていうのがちょっと話で出てきました。
そこでだからOSSのポッドが増えるコストよりもマネージドの機能を使うときのコストの方が高いってことなんですよね。
そうですね。
そこで言ってるコストはだから運用コストの話ではなく、
お金の方の。
そうですね。
利用料の話ですよね。
利用料の話です。
じゃあそういうことをやって実際どういうことが起こったかっていうと気づいたらアプリケーションのポッドよりそういったOSSのポッド割合がめちゃめちゃ増えてましたと。
はい。
これは完全にちょっと泥臭い話になっちゃうんですけどめちゃめちゃ大変だったのがクーバンディティスのクラスターをバージョンアップした際にこういうOSSのポッドって全てがあったわけじゃないんですけどデモセットっていう属性が多いんですよね。
はいはい。
各ノードに必ず1台ずつ配備されるようなスケジューリングされるようなポッドが多くてですね。
デモセットが多すぎて結果ノードに乗っからない問題がめちゃめちゃ起こってですね。
1ノードにアプリ1個しかいないのに他全部デモセットのポッドみたいな。
OSSのキャッチアップとコスト、リスクについて
メモリとかリソースの計算がちょっとめんどくさいというか。
そうなんですよ。
なので例えばプロメテウスとか乗っけてしまった日にはそいつがめちゃめちゃメモリとかリソースの予約取っちゃってるので全然他のもの乗っからないとか。
っていう何でしょう何と戦ってるんだろうみたいな感じの大変な問題が起こったりとか。
あとはもうOSSを使う上での避けられないところだと思うんですけどOSSのキャッチアップ使えますねっていう。
確かにけどでもあれですよね。
それはクラウドの提供する機能であってもキャッチアップは一応ありますよね。
そうですね。キャッチアップした上でのマイグレーションというかバージョンアップ対応が少しやっぱOSSの場合だとコストかかるなと思いましたね。
確かにそれはありそう。
しっかり移行方法書いてくれてるものもあればちょっと上げたらなんか急に動かなくなったぞみたいなものもあったりとか。
なんかちょうど最近自分が監視系の本読んでたりとかするんですけど。
その中でいわゆる観測者効果っていうのが言われてて。
監視をするためにそのメトリクスを取るための処理が実処理に影響を与えてしまうっていう。
それは大体どの監視系の本読んでもまあ無視していいよっていう感じなんですよ。
そうなんですね。
だって例えばLinuxでトップコマンド打ったりとかするときのそのトップコマンド自体の負荷っていうのは無視できるレベルだから。
確かに確かに。
そういう文脈で大体無視して良いっていう感じになってるんですけど今回はそれがその監視のためだけのそのポッドばっかりじゃないでしょうけど。
なんかちょっと無視できないレベルになっちゃったって感じですね。
そうですね無視できないレベルになりました。
ちょっとそういうことが起こってしまいましたと。
そこから私たちが少し学んだものとしてはOSS入れる分にはもちろん予算とかお金面でいうところのコストはかからないんですけど、
メンテナンスコストとか俗人化してしまうリスクとかっていうところも含めてのトレードオフを考えて場合によってエンタープライズのものを導入するべきだということを今更ながら改めて思いましたし、
あとはいろいろOSSが入れられるようになったってどういう背景があるんだろうなって思うとやはりKubernetesのエコシステム周りっていうかエコシステムが成長してるってことなんだろうなっていうのも一因というか一つの要因としてはあったと思ってて。
何でもできるようになっちゃった。
Kubernetesのエコシステムと無制限なポテンシャルについて
そう何でもできるようになっちゃった。
ですよね。
何でもできるようになっちゃって、かつクラスターの操作大体できるから、すべてが悔いに見えるじゃないですけども、何でも悔いに見えて、じゃあこれもKubernetesクラスターの中に入れちゃえばいいじゃんみたいなことに陥っちゃった。
なるほど。
で、いろいろ悔いに見えて打ってみると最終的に自分たちのサービスに対してそれってちょっとオーバーエンジニアリングなんじゃないのみたいなところも見えてきちゃったっていうのがちょっと振り返ってみてわかったことでした。
でもね、世の中的にはやっぱりKubernetesはプラットフォームなんで、悔いとハンマーで言うとちゃんとしたハンマーではあるんですよね。
そうですね。
何でも打てちゃうんだよな。
何でも打てちゃう。
で、少し気になったのは、何でも打てちゃうんですけど、結構CNCFの技術のキャッチアップとかをするときに、一時期ちょっとプロダクト名いくつかあって忘れちゃったんですけど、
ディベロッパーになるべくKubernetesクラスターを意識させないようなツール、要はKubernetesのクラスター操作に慣れてない人がいかに低学習コストでクラスターにポットをデプロイできるようにするとかそういったツールが結構出てきてたなって時期があって、
なんかそういうツールが出てくる背景とかを考えると、やっぱそのこういうクラスター構築するってみんながみんなできるわけじゃないってことじゃないですか。
そうですね。
で、なのに、なのにって言ったらあれだけど、エコシステムすごく育ってて、どんどん入れていくと本当にその自分たちの首を逆に締めてるようなことになりかねないなって思って。
で、これが世の中的にKubernetesクラスターとか使ってる企業とかサービスってみんないい感じにポットの割り入れとかできてるのかなって思ってちょっと調べてみると、
DynatraceのKubernetes in the wild report 2023ってやつがあってですね。
はい、今そのURLを見てます。
はい、その中にすごく興味深い項目がありまして、どこだっけな。
インサイトが得られてと書いてあって、1から1,2,3,4,5,6まであるのかな。
そうですね。
インサイトの多分3か。
3。
Kubernetesはクラウドのオペレーティングシステムとして扱われますみたいなやつですね。
ここの文章に実は同じようなことが、同じような特徴が書かれていて、
そのまま読むと、2021年には典型的なKubernetesクラスターではアプリケーションのワークロードのポット、
ここで言ってるワークロードって一旦私は純粋にアプリケーションだけだというふうに仮定してるんですけど、
そのポットが59%、6割ぐらい。
それとは対照的にシステムワークロードとか補助的なワークロードは反対だから40%ぐらい。
っていう割合でしたと。
ただこれが2022年になる頃には、このワークロードが逆転していて、
補助的なものが6割、アプリケーションが4割ぐらいっていうふうに、
世の中的にも立場が逆転し始めてるとか、数が逆転し始めているので、
Kubernetesにおけるワークロードの変遷
大かれ少なかれ、みんなそういう動きになってるんだなっていうことを知れた。
と書いてありますね。
これ2021年から2022年にかけて何か大きな変化があったのか、
それともやっぱりその2020年とか2019年からこういう傾向があって、
その順調な変化なのかどっちなんでしょうね。
ちょっとそこの詳細は何とも言えないんですけど、
個人的にそこの大きな変化がもしあったとすればというか、
おそらくですけど、主にやっぱ果敢促成の部分なんじゃないかなと思っていて、
以前このゆるテクでも博多家さんが紹介してくださったと思うんですけど、
DevOpsレポートとかでしたっけ、
その中にオブザーバビリティとかの話があったと思ってて、
要は果敢促成について着目されるようになって、
クラスターの果敢促成を高くするためのツールってどんどん提供され始めて、
みんながそういうのを入れ始めるとドカッとここら辺が増えてきたのかなと思ってます。
そうですね。
事実私たちも、例えばデータドックであったりとか、
あるいは独自のエクスポーターいくつか作ってたりとか、
あと変更禁止はちょっと果敢促成とは少し違うかもしれないんですけど、
ファルコとか入れてたりとか、
あとはどうでしょうね、果敢促成とはこれも違うけど、
多分GitOpsとかが流行ってるというか、
一般的になってきてるっていうのもある意味補助的なPodワークロードが増えてる理由なんだろうなと思ってます。
そうですね。
ここの例としてもそういうふうに書いてあるのかな。
他にどんな例があるんだろう。
メッセージングとか、サービス、セキュリティって何でしょうね。
セキュリティだとやっぱり侵入禁止とかそういったものじゃないですか。
そういう動きをしてくれる。
ものがやっぱりありますね。
なるほどですね。
有名なのとかだと、ゲートキーパーとかでポリシーチェックするとか、
ああいうのも多分入ってると思いますよ。
なるほどですね。
なので良くも悪くも、この中で大体のことが現地でやるとできちゃう。
できちゃいますよね。
逆に運用する人としても、さっきマシオさん補助的なワークロードが増えたらメンテナンスコストがあってお話しされてましたけど、
Kubernetesのクラスターを運用する立場としては、
やっぱりKubernetesで全部完結してくれた方が楽だったりする面もないですか。
あります。
クラウドのサービスを使うよりは。
めちゃめちゃありますっていうところなんですけど、
ふと思ったのは、例えばクラウドの何かのサービスを使った場合って、
サービスの専門性にもよると思うんですけど、
場合によっては、Xアザサービスみたいなチーム編成というか組織編成になるんじゃないかなと思ってて、
例えば、昔だったらセキュリティの何かのツールってなった時に、
きっとセキュリティの専門家たちがいるところはいて、
その人たちがそのシステムツールに責任を持ってたんじゃないかなって思うんですよ。
わかんなかったらそこに聞いてねーじゃないですけど。
クラウドに集約されて、私たちがやってるところはそんなに大きな規模のチームではないんで、
Kubernetesのクラスターを運用する立場としての難しさ
大きな規模のチームだと違うのかもしれないんですけど、
クラスターに集約されてるから、もちろんクラスターのことはだいたいわかるから対応できるんですけど、
そのさらに細かい補助的なワークロードの詳細までをこと細かに全部追いかけるのが、
今めちゃめちゃ辛いって感じがします。
気をつかなきゃいけなかったりするわけですよね、ワークロードによっては。
そうです。
とあるタイミングとかで急にCPU使用率とかメモリの使用量が上がったりとか、
みたいなところの動きを把握するのが辛いとかそういう系ですか?
そういう系です。
それは確かにきついですね、製品によって違うし。
そうなんですよね。
それぞれをインプットして修縮していくこと自体は、
正直エンジニアとしてはめちゃめちゃ楽しいフェーズだし、
できることが増えるっていうのもいいことなんですけど、
漏れなくなんとなくこれは俗人化がついて回ってるような気がして、
ならなくてですね。
確かにな。
っていうことをちょっとバージョンアップしてるときに話しながら考えてましたね。
これバージョンアップのときって多分あれですよね、
今動いてるクラスターと別クラスターをドーンと用意して、
多分ガチャンっていく感じですよね。
そうですね、ブルーグリーンみたいな感じですかね。
やっぱバージョンアップのときにクラウドの提供するサービスとかだったら、
熊本鉄のクラスの外の話なんで、あんまり注意を払う必要はないと思うんですけど、
バージョンアップ作業の中では。
中でやってると一個一個の動きが結構おかしくなったりしましたか、今まで。
しました。
やっぱするんですね。
クラスターのバージョンアップに伴う問題
APIの依存関係であったりとかが私たちの場合はすごく多くて、
Kubernetesクラスターのバージョンアップに伴ってKubernetesのAPIが少し変わって、
それに伴って使ってるOSSがそこまで対応していないとか、
あるいはもっと先を対応しちゃってて微妙にマッチしないとか。
なるほど、つらい。
っていうのはありましたね。
それによって逆にロックされて、これ以上のバージョンが上げられないよねとかって話もやっぱり出たりするんですよね。
それちょっと厳しいですね。
厳しいです。
そういう時どうしました?
いくつかパターンがあって、
一つは素直に問題ないバージョンであれば一旦そこのバージョンに止めるっていう選択肢もあるじゃないですか。
もう一つはフォークして、少し直して、自分たちのコンテナレジストリとかに一旦登録して使う。
それがあれですよね、フォークしてプレリクを送って取り込まれるような変更ならいいんですけど、
そうです。
完全に自分たち専用の変更だとつらいですよね。
そうなんですよ。
そういうのだとだいたい次のタイミングあたりはちゃんとリリースとして対応されてて、
Kubernetesバージョンアップの課題
これでやっとコントリビューターがしっかりいる場所に戻れるねみたいなことはあったりはしますよね。
なるほどな。やっぱりKubernetesのバージョンアップは大きいもんだな。
そうなんですよ。このあたり簡単にやってるんだとかあればめちゃめちゃ参考にしたいんですよね。
みんな絶対苦労してる。多分年に2回くらい来るはずですよね、確か。
そうですね。今だとサポートとかも落ち着いてきたから、今だと年2回くらいとかですよね。
昔だと多分多い時4回とかですよね。
そんな来てたんだ。半年に1回くらいのイメージでした。
年4回つらいですね。
そうなんですよ。だいぶIACとかGitOpsやってたとしてもちょこちょこ動かなくなるっていう悲しいことが毎回起こってますね。
バージョンアップのたびに新しいバージョンが出るたびにアップロードしなくても、クラウド側のサポートが切れたりしますよね。
そうですそうです。おっしゃる通りです。
それでは絶対上げなきゃいけないだろうから、どっちにしろそんな据え置きはできないですよね、Kubernetesを使う以上。
です。ある意味、よく昔ながらの保守ってどうせ何か言われた時に直せばいいんでしょうって考えてた人たちっているじゃないですか。
はい。
でもそういう技術の移り変わりもあって保守ってそれだけの話じゃないんだよっていうことがようやく広まってきた感じがするので。
確かに。
真剣に保守運用と向き合えるようになってるんじゃないかなと思ってます。
そうですね。説得もしやすくていいですよね。何もしないから壊れるんだよっていう。
そうそう。何もしないから壊れるんだよ。一番説得力のある言葉ですよね。
それが最近広まってきてるから言いやすいですよね。
私は今Kubernetesでそういう話をしたんですけど、博多家さんはいかがですか。
例えばOSSってそれぞれだからシンプルに開発してるアプリケーションでもそういうことって起こるじゃないですか。
起こりますね。
なんかそういう何でしょうね。OSSのメンテナンスってこれまでしっかりした流れでやってたことってあります?私あんまなくて。
OSSのメンテナンス
えっとですね。がっつりOSSのメンテもちろんないんですけど、自分がその業務とかで使っているOSSというかバージョンアップが必要なもので
バージョンアップが結構手遅れ気味になったことはありますね。
手遅れ気味。
バージョンアップを。定期的にやっているならいいんですけど、バージョンアップにももちろん作業が必要で、そんなことをやっている暇はないみたいな感じになることっていうのはまああることで。
あー確かに。
それでバージョンアップが末を置かれた結果、取り返しがつかないというか一気にサポートがきつくなってしまったことはありますね。
例えば他に使っている言語のフレームワークがそのバージョンをサポートしていないとか。
確かにありますね。
そのさっき水長さんがおっしゃったように、Aというライブラリはこれ以上のバージョンしかサポートしていないのに、
Bというライブラリはこれ以上をサポートしていないみたいな状態とかですかね。
ありますね。
それに気づくのが遅れるっていうパターン。
そういうのって、私がよく聞くのは何でしたっけ、リノベート?
GitHubがリノベート、違う、Dependabotか。
Dependabotか、はいはい。
どっちもあると思うんですけど、多分GitHub禁制だとDependabotの方かな。
そういうものを使えばキャッチアップできそうな気配もするんですけど、使ったことあります?
あります。あれ出た当初だったかな。結構割と勝手に通知してくれてたりしたんで、特にノードですね。
ノード系のライブラリは多分してきたと思うんで、使ったこと自体はあるんですけど、
本当は世の中に対して懺悔するんですけど、無視し続けていて。
いやー、分かりますよ。分かります。
そういう感じの悲しい記憶しかないですね、あれ系には。
まるで誰も感動しなくなったシステムのアラート並みに無視しますよね、きっとね。
はい。悲しくその通知が鳴り響く。
そうなんですよね。こういうのをちゃんとライフサイクルとして入れたいですよね。
1回遅れるとやっぱり取り返すの大変なんで、遅れないのを維持することに、もし先頭まで行くことがあれば維持したい。
だから三宅さん今あるじゃないですか、ちゃんとKubernetesはバージョンアップに追随してるじゃないですか。
はい。
この状態は絶対に崩さない方がいいと断言できますね。
そうですね、Kubernetesは絶対崩したくないですね。
だしそれも許されてないですもんね、Kubernetesのライフサイクル的に。
テラフォームのバージョンアップ課題
1回そのテラフォームを崩してしまってですね。
0.12とか0.11とかあの辺ですかね。
あの辺ですかね。確か12から13だったか、11から12だったかで、ステイトのマイグレーションがすごく面倒くさいタイミングがあってですね。
それを1回サボった時にめちゃめちゃ痛い目に遭いました。
ステイトだったか忘れましたけど、たぶん11と12の間がすごい障壁があったバージョンだった記憶はありますね。
そこかなたぶん、そこですよねきっと。
その時にだいぶ、完全に全部言い訳なんですけど。
もうわかります。
テラフォーム自体もすごくパイプラインを組んでたんですよ。
イミットとかプランとかバリデートでちゃんとある程度チェックして構文大丈夫とか設定値ミスってないとかっていうテストもその時パイプラインで組んでて。
失敗したのがめちゃめちゃ作り込んだんですよね。
例えばテラフォームで言うと、イニットした時に関連するモジュールとか全部取ってくるじゃないですか。
そこもなるべくパイプラインの時間を短縮したいので、ある程度共通のパスを設定して、一番最初にだけイニットしてあと全部同じのを使うとか。
OSSのバージョンアップとリリースノートについて
作り込んでたりしたんですけど、たぶん博多家さんがおっしゃる1.1から1.2ぐらいのタイミングで、そこら辺のパスも全部変わっちゃったんですよ、中身が。
覚えてないけどあったかも。
イニット後のディレクトリ構成がそもそも変わって、そのタイミングで一瞬心が折れたんですよね。
今回はいいかなって。
つらい。
それで思い出したんですけど、テラフォーム自体のバージョンもあるんですけど、プロバイダーのバージョンも結構破壊的変更が。
ありました。
結構あると思ってて。
ありましたありました。
博多さんのところはAzureじゃないですか。
そうですね。
Azureちょっとわからないですけど、AWSだとあれがあったんですよね、その1.1とか1.2らへんより後なんですけど、オブジェクトストレージのS3ってやつがあって、
あれの書き方とかがゴリッと変わる事故があって。
マジですか、はいはい。
それあまりにもひどかったんで確か戻されたんですけど、今どうなったかな、元に戻ったかちょっと忘れたんですけど。
なるほど。
それもあるなと思いましたね、プロバイダー。
ありました、確かに。
今博多さんがおっしゃってくれたように、私たちはAzure使ってるんですけど、ちょうどバーチャルマシン、AWSで言うと多分EC2とかそういう。
EC2ってのがありますね。
バーチャルマシンの定義の仕方がゴリッと変わったタイミングが確かにあって、もともとそういう仮想マシン作る時ってWindowsマシンなのかLinuxなのかとか色々あるじゃないですか。
昔まで一つの定義でオプションでWindows、Linux書き換えられてたんですけど、そもそも定義が変わって、Windowsだったらもうリソース名がそもそも違うみたいなことになって、最初モジュール化とかして共通化してたんでゴリッと変えましたね。
ただ、クラスターとかクラウドリソースの新機能を使うには、使いたい場合って基本APIとかのバージョンを上げないと設定できないことが多いので、必然的にテラフォームのプロバイダーのバージョンも上げていくことにはなりますよね。
なりますね。なるべくロックしないように。
そうなんですよ。
新機能が新しく出たサービスが使えないぐらいだったらまだいいんですけど、互換性によってそのうち今使っているAPIのバージョンがサポートされなくなって動かなくなるとかも全然あり得るんで。
そうなんですよね。それこそあれですよね。以前、博崎さんがたぶん雑談のときに私に紹介してくださったテラフォームのカールリソース。
そこまでやるならもう普通なのみたいなやつですよね。
カールリソース使ったら無敵なんじゃないかみたいなのありますけどね。
でもそれちょっとの仕様変更も全部自分でやらなきゃいけないからきついですよね。
それは絶対きついですよね。
きついですね。面白かったなあれ。
ついにカールコマンド叩けちゃうんだってなりますよね。
なんでもできるんじゃんみたいなやつですよね。
なので、IACとかGitOpsとかコード化できることはめちゃめちゃ便利ではあるんですけど、
あくまで流すとこは簡単だけど、常に情報を更新してメンテナンスしなきゃいけないっていうのはある意味変わらないは変わらないですよね。
そうですね。継続的にやっていかないと。
本当にいろんな人が口すっぱくして言ってますけど、バージョンアップは溜めてやるよりもちょっとずつやったほうが絶対楽ですね。
絶対楽ですね。
本当に絶対楽。
間違いなく。
せいぜいパッチバージョンとかだったら、別にちょっとぐらい溜まってても大丈夫だと思うんですけど、
マイナーとかメジャーが変わった日にはって感じしますよね。
特にメジャーバージョンは見過ごしちゃダメです。
目を瞑っちゃダメですね。
別物ですからね。
新機能の追加について
即刻スケジュール組んでやらないと。
そうなんですよね。
ただどうでしょう。
めちゃめちゃもちろん大変なんですけど、
リリースノートとか追いかけてると、新しくこういうことができるようになったんだなっていう発見があるってところは、
何とか続けられてる楽しみというか、
には個人的にはなってます。
ワクワク感がありますよね。リリースノート。
あります。
いいですよね。
こういう新しくできることに増やしたんだとか、
最近のトレンドがこうだから、このOSSも対応してきたんだなとかってありますよね。
クバネテスぐらいになると多分あると思うんですけど、
この機能が入ったんだったら、
その機能がないがためにこういうことしてたみたいなワークアラウンドがなくせるじゃんみたいな喜びとかあったりしません?
IACやGitOpsによる設定の継続的な更新について
あります。
クバネテス自体に対してもありますし、
マネージドな各クラウドが提供しているクバネテスサービスを使っていると、
そのマネージドなもののアドオンとして便利な機能が追加されてたりとかもあるんで、
そういったところも結構使わせていただいている状態ですね。
いいことだ。
いいことです。
クバネテスに限った話じゃないですけど、
OSSのバージョンアップ大変だよねっていうところであったり、
エコシステム育ってくるとシステムの構成ってめちゃめちゃ変わってくるよねっていう話が
2人でできたので、私はもう満足です。
ちなみにこのバージョンアップ作業の途中に気づかれたって話でしたけど、
今回どうですか?終わりましたか?
終わりました。ちゃんと2時間ないぐらいで終わりました。
素晴らしい。お疲れ様です。
ありがとうございます。ただGitOpsとかIACやってると、
どんな構成にしてたっけな?はめちゃめちゃ忘れますね。
確かに。でもそれを定期的にこういう作業があるから思い出せるというか、いいですね。
ぜひこういう風にやると簡単だよとかがあれば知りたい。切実です。
確かに意外と見てない。あるのかな?
KubernetesのCRT、カスタムリソースディフィニッションの実装
クラスターバージョンアップのあれこれってそんなに見ない気もする。
でもこんだけ汎用的なトピックだったらありそうだけどな。
見てないだけかも。
あとはわからないですけど、私が全然手を出してないとこですけど、
自分でKubernetesのCRT、カスタムリソースディフィニッションとかを実装する人たちからすれば、
もしかすると自前でそういうめんどくさいところにいい感じでチェックしてくれるものを作ってそうだなと思ったりはします。
なるほど。
まだそういうものを作ったことはないので、チュートリアルがあればやってみたいなと思ってますけど、ちょっと探してみようかな。
いいですね。
はい、じゃあ今日はそんなところでおしまいにしましょうかね。
ゆるいテクでしたね。
ゆるいテクでしたね。
いや、ゆるくないですよこれ。
いやいや、ゆるかったですよきっと。
たまに言われるんですよ、嬉しいことに。
これ聞いてくださっている方とかに、たまにゆるくないネタあるよねって言われます。
そうなんですね。
何よりも聞いてくださっていることが嬉しいので、ありがとうございます。
ありがとうございます。
おわりの言葉
はい、じゃあ締めの言葉を言いますね。
はい。
Twitterではハッシュタグゆるテクをつけてツイートをお願いします。
Googleフォームからも感想をくれるのでよろしくお願いします。
今日はありがとうございました。
ありがとうございました。
