egashira.dev
Published on

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

はじめに

書籍「Kubernetes で実践するクラウドネイティブ DevOps」を読んだので自分なりのまとめや感想などを書いておく。

O'Reilly Japan - Kubernetes で実践するクラウドネイティブ DevOps

感想

内容としては、Docker イメージのビルドから Kubernetes(以下 k8s) 上でアプリケーションを運用する際の継続的なデリバリーなど"コンテナ"という領域で網羅的に扱われている一冊。また「実践する」とタイトルにある通り、割とツールの紹介も多かったり、実践的なプラクティスが紹介されていたり運用面の知識を得ることができた。

個人的には、本書の対象として DevOps エンジニアやクラウドエンジニア、SRE の中でも k8s 上でのアプリケーション開発や運用を日頃から行うような人におすすめだと思う。僕は k8s の基本的な部分は触ったことがある程度で、運用の経験はほとんどないので、同じように運用経験が浅い、あるいは何かしら現在の運用に課題感を持っている方などに丁度いいのかなと思う。

全体の構成

全てを紹介するととんでもないボリュームになりそうなので、個人的に関連性の高い章ごとにまとめて紹介する。

1 ~ 3 章

クラウドやコンテナのいった技術の流れがわかりやすくまとめてある。なぜクラウドや Kubernetes というものが必要となったのか、DevOps という考え方がこうも広がったのかを流れに沿って書かれている。

k8s は難しく高可用性を保った上での管理は大変なので、マネージドサービスを利用するべきだということやビジネスの観点からは管理するソフトウェアを減らすというのも選択肢として挙げられており、運用者目線での意見が強めだなと言う印象。

4 ~ 8 章

Pod, Deployment, Service などの k8s オブジェクトの基本操作。あとはクラスタの運用などの話に移っている。ここでの学びは…

  • Annotation を使って使用率が低い、放置されたままのリソースを取り除いてクラスタの状態をクリーンに保つ
  • 使わなくなったら、Namespace ごと削除する(全てのリソースが削除されるため注意)
  • default Namespace は間違いを起こしやすいので使わない
  • どの Namespace でも ResourceQuota を使って Pod の数を強制的に制限する
  • 高可用性を確保するには、最低でも 3 台のマスターノードが必要
  • コンテナは 1 つだけのプロセスを実行するように設計し、latest タグは使わない

などだろうか。

9 ~ 11 章

k8s の Pod に焦点を当てつつ深い話に入っていく。Label, Affinity, Tain/Toleration などの機能から CRD、マイクロサービス関連で Istio や Envoy の紹介も入っている。

続いてセキュリティの話に入っていく。この辺は CKS を受験する際にもう一度読んでおこうと思う。

12 ~ 16 章

実際に k8s 上での開発や運用に使用するツールが多く紹介されていた。書籍発行から 2 年ほど経っていて GitHub を見たら archived になっているものもあり k8s 界隈の変化の速さを再認識させられた。

ユーザも多いであろう Helmkustomize といった k8s のマニフェストファイルの運用を効率化してくれるツールの概要に触れられていたり、skaffold などの便利ツールの紹介もされていた。

また、重要なトピックとしてはデプロイ戦略について書かれていた。この辺は、k8s の宣言的なリソース定義というメリットをいかに活かすかという話なので、個人的には深堀りたいところだなと思った。

学びとしては、Dockerfile のビルドでマルチステージビルドを使用している場合、ステージごとにタグ付けしておくとキャッシュによりデプロイを高速化できたり、テストもしやすかったりとなにかとメリットがあることを知ったのでこれは実践していきたい。

オブザーバビリティと監視の章では、オブザーバビリティの概念から、いかにしてエンジニアリング組織を作っていくかや、メトリクスをビジネスに活かすかが書かれており、この辺りも非常に僕好みの内容で興味を引かれた。

印象に残ったフレーズ

この手の書籍は名言という名言がいくつか登場する。中でも勉強になったことや単純にカッコいいなと思ったものを紹介する。

DevOps の第一歩は、最先端のソフトウェア開発はコードをリリースしたら終わりではないと認識することです。それは、コードを書くものとそれを使用するものとの間のフィードバックループを短くします。

現在で広く認識されつつあるのかなと思うが、重要なこと。

何もない状態から Kubernetes を本番の設定で運用し始めるためには、エンジニアの給与で約 100 万ドルが必要になる推定しています(「それでも目的を達成できないかもしれません」)。

実際の数字はさておき、意図は分かる。自前で運用するコストは半端じゃない。マネージドサービスを使うことに経営陣が納得しない場合は、こういう話をするといいという著者からのアドバイス。

alpine などのベースイメージだからといって自動的に信用すべきではない

その通り。あとはベースイメージや依存関係にも脆弱性がないかスキャンツールを使って確認することを勧められていた。

ユーザがハッピーでなければ 9 の数に意味はありません。

可用性イレブンナインの話。

オブザーバビリティとはまさに文化で、コードの開発と本番での大規模な実行との間のループを縮めることが、DevOps 哲学の基本理念です。

モニタリングやロギングということについては AIOps 系のサービスが巷にはいろいろある。なのでツールを導入すれば運用を効率化できるようにはなっているんだけれども、どうしてこういう必要があるのかを理解した上で文化を築いていくことが大事だし、それが一番難しくはあると思う。

まとめ

内容盛りだくさんで基礎的なことからかなり丁寧に解説してあったと思う。 コンテナ、クラウド、k8s の基本的な知識がある状態で読んだので、理解が曖昧だったところの補足や、便利ツール、運用のことなど知れたのは良かった。

参考