Kubernetesを使いこなす：トラブルシューティングからシンプルさへ

Kubernetesはコップの半分が空なのか、半分が満杯なのか？それはあなたの見方次第だ！Kubernetesのオーケストレーション機能の仕組みは（私見では）かなり複雑で、経験豊富な実務者であっても、そのために壁に頭をぶつけることは珍しくない。その一方で、初心者ユーザーや、技術的負債を背負うキャパシティが限られているビジネスケースにも、ハードワークではなくスマートワークのために、私はしばしばこれを勧めてきた。私はフリーランスとして2つ目のアルバイトをしており、小さな非営利団体のシステムを保守している。だから、1日8時間子守をする時間がないときは、K8sに重い仕事を任せることができれば、私たち全員にとってより良い生活が送れる。さらに良いことに、もし私が大企業で働いていて、1日8時間子守をするために給料をもらっているとしても、K8sのパワーを活用して子守のほとんどをやってもらいたいと思います。これは、K8sを自分の生活を楽にしてくれる味方だと考える、グラス半分の視点だ。あなたが望むことを宣言し、K8sにベストを尽くしてもらう。

このアプローチは単純すぎると思われるかもしれないが、物事を複雑にしすぎる傾向も指摘したい。例えば、まだ目処も立っていない "将来への備え "のために過剰なエンジニアリングを行ったり、すでにそのタスクのために構築された実績のあるツールを使わず、車輪を再発明したりするような場合だ。プラットフォーム・エンジニアリングへの飛び込みも例外ではないが、これについては次の記事で詳しく説明しよう。

K8sは強力で複雑な組織体ですが、私たちの業界の同業者の多くが、K8sを「ただ動く」ものにするために何時間も費やしてきたことを忘れないでください。

私が初めてKubernetesに触れたのは、Linode Kubernetes Engine（LKE）をリリースした2019年、Linodeのカスタマーサポートチームの最前線でのことでした。ユーザーからの要望があまりに膨大だったため、沈むか泳ぐかの瞬間でした。私たちはこの製品をサポートしなければなりませんでした。つまり、私たちはこの製品を学び、さらに良いことに...トラブルシューティングをしなければなりませんでした！イライラすることもありましたが、これは私のキャリアの中で最も貴重な経験でした。

この記事では、私のような実世界での経験に基づき、Kubernetesを学び管理するためのいくつかの戦略を探る。

実践で学ぶ

プラットフォームを真に理解する最良の方法は、次のようなものを作り、壊すことである。 壊すことだ。ことだ。ドキュメントとチュートリアルを組み合わせることは、動作するクラスタを手に入れるための素晴らしい方法です。マニフェストをGitレポに放り込めば、永遠に参照し続けるテンプレートができあがります。次に、それを壊す面白い方法を見つけよう。これは友人や同僚にやらせて、診断を始めるまで問題の原因がわからないようにすることだ。あるいは、ガイドで紹介されていることよりも複雑なことをやってみるという方法もある。例えば、Linux Foundationが提供するCKADコースを受講しているとしよう。彼らは、単一のコントロールプレーンと1つのワーカーノードだけで単純化したクラスタを構築するように指示するかもしれない。その代わりに、高可用性のために3つのコントロールプレーンノードと3つのワーカーノードを持つクラスタをうまくブートストラップしてみてください。それでも難しければ、VPCを実装し、IP空間での衝突を避けるためにクラスタ・ネットワークのアドレッシングをカスタマイズしてみてください。たとえ時間が経って挫折してタオルを投げてしまったとしても、そうでない場合よりも多くのことを学べたはずだ。これらは私自身の経験から得た2つの例に過ぎない。限界はある。

さらに、Minikubeや Kindのようなツールは、クラウド上の何かを触る前にローカルで実験するのに非常に役立つ。 クラスターの破壊、トラブルシューティング、修正をどのように行うにせよ、必ず何らかのドキュメントを残しておくこと。手順や解決策を明確にする必要があるため、書き出すという行為は記憶にも残る。もしこれを公開する時間があれば、自分の優れたトラブルシューティングの方法論を披露できるだけでなく、仲間を助けることにもなる。

学びの道としてのトラブルシューティング

トラブルシューティングの方法論について言えば、「ベストプラクティス」というものは存在しない。重要なのは、自分自身でこの筋肉を鍛えようとする意思を持つことであり、それは時間とともに容易になる。私が出会った最高のトラブルシューターたちは、まさにこれを何年も続けてきた結果、彼らの前では何でも投げられるようになった。その結果、彼らの前では何でも投げられるようになった。 

私にとって最も効果的なテクニックをいくつか紹介しよう：

• 分割統治：問題を半分に切り、潜在的な原因を体系的に排除する。計画的に積み重ねる方が簡単だという人もいるだろうが、私は通常、まず除外できるものから手をつけることに成功を見出す。他の人のアドバイスに逆らうことだろうか？そうかもしれない！しかし、私は自分にとって何が効果的であるかに重きを置いている。
• Monitoring 観測可能性はあなたの友人であり、エラーもまたそうである：メトリクス、ログ、トレースはシステムの全体像を描き出し、さらに問題の全体像を描くことができる！Prometheus Grafana モニタリングのデファクトであり、ログ集計とトレースツールの選択と相性が良い。しかし、現実の世界では、常に完全な観測可能スタックに恵まれているわけではありません-時には、Prometheus Grafanaスクレイピングするためのいくつかのリモートターゲットがベストです。幸いなことに、それでも多くの場合、これは非常に長い道のりを歩むことになる！もちろん、いくつかは他のものよりも役に立つが、それにもかかわらず、これは何かがうまくいかなかったという情報を持つシステムからのフィードバックである。
• 問題を再現する：可能な限り、別の環境で問題を再現する。そうすることで、原因に関する豊富な情報を得ることができ、解決策を見つけるための扉を開くことができます。それはまた、安全に実験できるテスト環境があるということでもある。コードとしてのインフラ （IaC）の力を活用することが良い習慣である多くの理由のひとつは、必要に応じてこの環境を素早く再現したり破壊したりできることだ。たとえそれが自分で書くことを意味するとしても、環境が以前にコード化されていない状況では、前もってこれに少し時間を費やすことで、その後の時間を大幅に節約することができる。
• トラブルシューティングログを残す：アーキテクチャー決定記録／ログという概念に馴染みがあるかもしれない。同じようなコンセプトをトラブルシューティングに適用しない手はないだろう？何もない！特別な書式や慣習は必要ない。トラブルシューティングのステップを記録するだけです。これは、後戻りしたり、すでに除外したことを再度確認したりする必要がある場合に便利です。さらに良いのは、解決策を文書化し、そこにどのように到達したかを説明するために、後でそれを見直すことができることです。ステップとその背後にある論理を明確にすることで、あなたの記憶により永続的な足跡を残すことができる。また、あなたの文書を読む人にとっても役に立つだろう。このドキュメンテーションに適しているのは、社内のナレッジベース・プラットフォーム、あるいは他の人に教えるための一般向けブログだ。 

特に難しい問題に直面したとき、トラブルシューティングを学習の機会として受け入れることは、問題解決スキルの長期的な向上につながり、インフラ管理方法の改善に役立ちます。デバッグのプロセスを洗練させ、反復させるチームは、Kubernetesのパワーを享受するためのより良い環境を手に入れることができます。

シンプルで信頼できる技術を使う

クラウド・ネイティブのエコシステム（そしてクラウドの全体的な状況）は、つなぎ合わせるためのツールやフレームワークを数多く提供している。構築できるものの可能性は無限に近い！しかし、この考え方はしばしば大きな落とし穴につながる。ツールが多すぎ、複雑すぎ、技術的負債が多すぎるのだ。幸いなことに、これはほんの少しの規律と考え方ひとつで簡単に避けられる罠だ。最高の技術とは、最も保守性が高く、最も安定した技術であり、ユーザーもそれに同意する傾向があることに気づくだろう。もしあなたが家の屋根に上るために梯子を登る必要があるとしたら、正しく使えているかどうか疑問に思うほど過剰に設計された梯子は欲しくないはずだ。それは恐ろしいことだ！

誰も読めないほど複雑なコードベースを維持することに誇りはない。ほとんど誰も使えないほど複雑なシステムを構築することに、金メダルやトロフィーはない。私たちが求めているのは、機能し、安定していて、さらに苦労を重ねることなく確実に正しく使えるものだ。ここでは、シンプルさがあなたの味方だ。また、クラウド・ネイティブ・デザイン・パターンとは、急速な変化を受け入れるものであることを覚えておいてほしい。アプリケーション・アーキテクチャは、それが進化するにつれて自然に複雑さを増していくものなので、無理にその手を使う必要はない。モジュール化されたクラウド・ネイティブ設計に加え、最小限のアプローチを採用することで、チームはよりスリムで安全なシステムを構築し、デプロイメント、メンテナンス、トラブルシューティングを効率化できる。 

さらに、シンプルに保つことで、パフォーマンスのボトルネックになったり、セキュリティ上の欠陥の攻撃対象になったりする設定ミスのリスクを減らすことができる。

Kubernetes自体は抽象化されたものだ。そうでなければ「クラウドネイティブ」とは呼べないが、不必要な抽象化を抑えることは、エンジニアが根本的な複雑さの管理に費やす時間を減らし、価値の提供に集中する時間を増やすことを意味する。というのも、私がこれまでのキャリアを通じて見てきた最も先進的なイノベーションは、「厳格な食事療法」のアプローチを体現する企業から生まれているからだ。

Kubernetesをマスターし続ける

実践的な経験、強力なトラブルシューティング方法論、ツールへの思慮深いアプローチを組み合わせることで、Kubernetesをより簡単にマスターすることができる。読むだけでなく）実践することで学ぶことは、実運用に不可欠な問題解決スキルを身につけるのに役立ちます。トラブルシューティングは、単に壊れたものを直すことではなく、理解を深め、ドキュメントを改善し、将来の課題を解決しやすくする体系的なアプローチを開発する機会なのです。また、不要な抽象化を最小限に抑えることでKubernetesスタックをシンプルにすれば、認知的なオーバーヘッドが減り、長期的な管理が容易になります。 

多くの経験豊富な実務家が学んできたように、明確なメリットをもたらすことなく複雑さを増すツールで過負荷になったクラスタよりも、無駄がなくうまく構造化されたクラスタの方が保守や拡張が容易だ。結局のところ、Kubernetesで成功するためには、市場に出回っているすべての新しいツールを使うことではなく、どのツールが長期的に本当の価値をもたらすかを知ることなのだ。 

Kubernetesについてもっと知りたい方は、KubeFMポッドキャストで詳しくお話しています。