しょ〜うぃん広場

おもにTech系なブログ、ときどき個人的なブログ

「Kubernetesで実践するクラウドネイティブDevOps」を読んでみた

LAPRASでは、AWSのEKSをつかってインフラを管理しているのだが、今後自分がインフラの面倒をメインで見ていくことになったので、社内のインフラエンジニアにおすすめの本を聞いてみた。 「Kubernetesで実践するクラウドネイティブDevOps」がおすすめとのことだったので読んでみたところ、とても良い本だったので紹介しようと思う。

ちなみに LAPRAS夏の自由研究リレー なるものをLAPRASメンバーでやっていて、これはその2日目の記事。 本を読むだけで研究なのかというツッコミはあるが、きっとこの後も面白い記事が続くと思うのでチェックしてみて欲しい。1日目の $ docker pull$ docker run を自作してみる話も面白かったよ。

moro-archive.hatenablog.com

本題に戻り、、

まず結論から

基礎から運用まで実践的な話が多く、インフラエンジニアとして現場でk8sの運用をしていく人にはかなり向いている本だと感じた。当然ではあるのだけど、コンテナについての基礎的な話はあまり書かれていないので、そこはある程度知識を持った上で臨む必要がある。中級者向けの本という感じ。

自分の場合は、もともとアプリケーションエンジニアとして、k8sのdeploymentを少し書き変えたりpodに入って作業することもあったので、k8sの目に見えやすい部分はざっくり理解した状態でこの本を読み始めた。その結果、曖昧に理解していた部分の復習に加えて、知らなかった部分の補完ができてすごく理解が深まったので、同じ立場の人にはおすすめしたい本である。

1~3章

k8sを取り巻く環境についてや、どのクラウドインフラプラットフォームのマネージドサービスがおすすめかなどが書かれている。本ではGKEイチオシと書かれているが、社内でAWSのEKSを使っていてもいままであまり不便を感じたことがない。自分で調べたところ、いずれのマネージドサービスでもk8sの最新バージョンから2世代ぐらい遅れたバージョンから利用可能という状況はあまり変わらないので、料金体系以外はあまり気にしなくてもいいのかなと思っている。

4~8章

k8sを使う上で最低限これだけは知っておきたいオブジェクトの操作だったり、リソース管理方法について書かれている。文中には「この本を読んでいるだけでは深く理解できないので、実際に手元のPCでk8sを動かしながら読み進めていくと良い」という旨が書かれていて、技術の勉強するにあたっては当然のことであるが、それをきちんと明記してくれるあたりいい本だなと思ったりした。

シェルのエイリアスはこうするのがいいよ

alias k=kubectl
alias kg=kubectl get
alias kgdep=kubectl get deployment
alias ksys=kubectl --namespace=kube-system
alias kd=kubectl describe

とまで具体的に書かれていることからも、どこまで"実践"を大事にしている本かを理解することができる。

9~16章

9章以降は少しずつ発展的な内容になっていくので、運用者以外は軽く流し読みしても良い内容なのかも知れない。もちろん有用なことは多く書かれているので時間があるなら読むに越したことはないが。

環境変数、セキュリティ、CI/CD、デプロイ戦略、開発環境、メトリクスなど話題は多岐にわたり、すぐに必要にはならない知識もあるので、一度軽く読んでおいて、必要になったら深く読み返すような使い方に向いていそうだと思った。

その中でも15章の"オブザーバビリティ"という概念は良かった。日本語にすると"可観測性"になるが、どこまで観測可能にしておくかということである。 例えば、k8s自身による監視機能や内部のメトリクスには異常がないのに、ユーザがWebサービスを見れなくなる原因として

  • DNSレコードの誤り
  • ネットワーク分断
  • パケットロス
  • ルータの設定ミス
  • ファイアウォールのルールの欠落または誤り
  • クラウドプロバイダの機能停止

などが考えられる。つまりk8sによる監視だけでは不十分であり、外形監視の仕組みを取り入れるなどしてオブザーバビリティを高める必要がある。

また、コンテナが標準の世界ではいつコンテナが終了するかもわからないので、ログのライフサイクルについても考え方の変化が必要で、ログアグリゲーターが各コンテナから抽出してコンテナの外に保存しておくことが必要になる。 オブザーバビリティに取り組むことで、事実とフィードバックに基づくエンジニアリングのチーム文化へと移行することができるという話もよかった。

まとめ

上述のように、基礎から発展的な内容まで網羅されていて、必要に応じてリファレンスとしても見返せる本である。リファレンスとして使える本は一般的に分厚くなりがちだが、350ページ程にまとまっていて、10時間弱で読み終えることができた。(リファレンスとして使えると言っても、この本だけあれば完璧というほどの情報量はないので、まずこの本でツールの選択肢とその特性を理解した上で、詳細はそれぞれのツールのドキュメントを読むことになると思う)

前任のスーパーインフラエンジニアがきちんと設計/運用してくれていたおかげで、自分自身はこの本を読み終えても「これやったらもっと良くなりそうじゃん!」的な要素は少なかったが、この本の内容を身に着けておけば中規模〜大規模サービスまでは面倒見れるようになると思うので超おすすめの一冊である。