【2023年】Docker/Kubernetes本「人気20冊と新書/高評価/おすすめの9冊」

体系的に分かりやすく書かれていて良書です。k8s公式などをドッグフィーディングして得た知識を補間できました。 (参考：YahooShopping)

[きほんのきほん]と書かれたタイトルに偽りなし。技術的な関連情報をあまり分かってない人にも優しい本。図解もよい。 (参考：YahooShopping)

Dockerの入門書としてお勧めの本。
一通りの操作と概念が手を動かしながら学べます。
挿絵については賛否があるようですが、自分としては特に気にならなく、Dockerの仕組みからHub、コンテナ間の通信、記憶領域のマウント／バインドと理解できました。
Docker fileとCompose fileの部分は、実際に作りたい環境があり(SeleniumとPythonコンテナをたてて、スクリプトをホスト側から適宜修整できるようにする)、ネットで情報を補完して作りました。ここは自分で作りたい環境を決めて、実際に作った方がいいです。
本書でDockerの概観を捉える事はでき、Dockerってなんなの?という学習前のモヤモヤは晴れました。
＊疑問点があれば自分で調べて理解できるレベルになった (参考：honto)

Kubernetesを中心としたテクノロジーを使ってDevOpsを実践するのに必要な知識とツールを解説した本。
Kubernetesとコンテナ技術の前提知識は不要とあるが、さすがにまったく知らないと学習曲線がきつく、読み進めるのは大変だろう。ただコンテナ技術の入門的な知識があれば、Kubernetesの概要から始まってDockerやKubernetesについて初歩からひととおり解説してくれるので、これから本格的に使ってみようという読者（私もその一人）には重宝するはず。
開発からテスト、運用、監視、セキュリティなど、CI/CDのパイプライン全体を俯瞰できるので、本書を一冊読めば、Kubernetesまわりの技術の全体像をある程度つかむことができる。Kubernetesのエコシステムは膨大で変化も速いので、どんなツールがあってどれが普及しているのかを知るだけでも大変だが、この本を読めば効率よくそれを知ることができる。
翻訳もこなれていて読みやすい。 (参考：honto)

1章　クラウドでの革命
■クラウドネイティブとは
・自動化可能
・ユビキタスかつ柔軟
・弾力的かつスケーラブル
・動的
・オブザーバル（観測可能）
・分散化

■まとめ
・クラウドコンピューティングによって、独自に保有するハードウェアを管理するための支出とオーバーヘッドから解放され、耐障害性、柔軟性、拡張性に優れた分散システムを構築できます。
・DevOpsの第一歩は、最先端のソフトウェア開発はコードをリリースしたら終わりではないと認識することです。それは、コードを書く者とそれを使用する者との間のフィードバックループを短くします。
・さらにDevOpsはインフラと運用の世界に、コード中心のアプローチとソフトウェア工学の優れたプラクティスをもたらします。
・コンテナを使用すると、標準化された小さな自己完結型の単位でソフトウェアをデプロイおよび実行できます。これにより、コンテナ化されたマイクロサービスを接続することで、大規模かつ多様な分散システムを構築する難易度とコストが低下します。
・オーケストレーションシステムは、コンテナのデプロイ、スケジューリング、スケーリング、ネットワーキングなど、優れたシステム管理者が行うであろう作業をすべて､自動化されたプログラム可能な方法で管理します。
・Kubernetesは事実上の標準となっているコンテナオーケストレーションシステムで、すぐにも本番で活用できる環境が現在すでに整っています。
・クラウドネイティブとは、協調して動作するマイクロサービスで構成され、自動化されたInfrastructureasCode(コードとしてのインフラストラクチャ)によって動的に管理される、クラウドベースのコンテナ化された分散システムを簡潔に表現するのに役立つ用語です。
・運用とインフラのスキルは、クラウドネイティブ革命によっても決して陳腐化するわけではなく、現にかつてないほど重要であり、今後もさらに重要性が高まります。
・中央チームは、他のすべてのチームがDevOpsを実現できるように支援するプラットフォームとツールを構築および保守するために、依然として存在意義があります。
・ソフトウェアエンジニアと運用エンジニアの明確な区別は今後なくなるでしょう。今ではソフトウェアがすべてであり、誰もがエンジニアです。

2章　Kubernetes最初の一歩
■まとめ
2.7まとめ
・すべてのソースコード例(および他の多くの資料)は、本書に付随して用意されているデモリポジトリ(https://github.com/cloudnativedevops/demo)から入手できます。
・Dockerを使用すると、コンテナをローカルにビルドしたり、DockerHubなどのコンテナレジストリにブッシュ(アップロード)したり、そこからプル(ダウンロードしたり、コンテナイメージを各自のマシンでローカルに実行したりできます。
・コンテナイメージの内容はDockerfileで完全に指定されます。これはコンテナのビルド方法に関する命令が記述されるテキストファイルです。
・DockerDesktopを使用すると、小規模な(単一ノードの)Kubernetesクラスタを各自のマシン上で実行できます。小規模とはいえ、ここでは任意のコンテナ化されたアプリケーションを実行できます。別の選択肢としてはMinikubeがあります。
・kubectlツールは、Kubernetesクラスタを対話操作する基本的な方法です。これは命令的に使用することも(例えば、公開されているコンテナイメージを実行し、必要なKubernetesリソースを暗黙のうちに作成)、宣言的に使用してYAMLマニフェストの形でKubernetes設定を適用することもできます｡

3章　Kubernetes環境の選択
■実行するソフトウェアを減らす
「実行するソフトウェアを減らす」という哲学には3本の柱があり、いずれも時間もうまく使って競争相手に打ち勝つために役立ちます。
１．標準のテクノロジを選ぶ
２．差別化につながらない面倒な作業はアウトソーシングする
３．長続きする競争優位性を生み出す

■まとめ
・Kubernetesクラスタは、コントロールプレーンを実行するマスタノードと、ユーザのクロードを実行するワーカノードで構成されます。
・本番クラスタは高可用性を備えていなければなりません。つまり､マスタノードに障害が発生しても､データを失ったりクラスタの運用に影響が及んだりはしないことが求められます。
・単純なデモクラスタは、重要な本番ワークロードに対応する準備が整ったクラスタにはほど遠い状態です。高可用性、セキュリティ、ノード管理は、取り組まなけばならない課題のごく一部にすぎません。
・独自のクラスタを管理するためには、時間、労力、専門知識を大量に投入する必要があります。しかも、それだけやっても依然として正しく機能しない可能性があります。
・GoogleKubernetesEngine(GKE)のようなマネージドサービスは、あらゆる面倒な作業をユーザのために、セルフホスティングよりも大幅に低コストで実行します。
・ターンキー方式のサービスは、Kubernetesのセルフホスティングと完全マネージドとの間で検討する価値のある妥協案になります。Stackpoint.ioのようなターンキーソリューションのプロバイダがユーザのためにマスタノードを管理する一方、ユーザは自分自身のマシンでワーカノードを実行します。
・独自のクラスタをホスティングしなければならない場合には、kopsを推奨します。これは広く使用されている成熟したツールであり、AWSやGoogleCloudで本番グレードのクラスタをプロビジョニングおよび管理できます。
・可能であればマネージドKubernetesを使用すべきです。これはコスト、オーバヘッド、品質の点で、大部分のビジネスにとって最善の選択肢です。
・マネージドサービスが選択肢とならない場合は、優れた妥協案としてターンキー方式サービスの使用を検討します。
・ビジネス上の明白な理由なしにKubernetesクラスタをセルフホスティングしてはなりません。どうしてもセルフホスティングに踏み切る場合は、初期セットアップと継続的な保守のオーバヘッドに伴うエンジニアリング時間を過小評価しないことです。

4章　Kubernetesオブジェクトの基本操作
■まとめ
・PodはKubernetesリソースの一種で、Kubernetesにおける仕事の最小単位であり単一のコンテナ、または組み合わせて同じノードにスケジューリングされ相互に通信するコンテナのグループを指定します。
・Deploymentは高水準のKubernetesリソースであり、Podを宣言的に管理し、必要に応じてPodをデプロイ、スケジューリング、更新、再起動します。
・ServiceはKubernetesリソースの一種で、ロードバランサやプロキシに相当する機能を提供し、単一かつ周知の永続的なIPアドレスまたはDNS名を通じて、条件に一致するPodのグループにトラフィックをルーティングします。
・Kubernetesスケジューラは、どのノードでもまだ実行されていないPodを監視し、それに適したノードを見つけて、Podの実行をノードのkubeletに指示します。
・Deploymentなどのリソースは、Kubernetesの内部データベースが保持するレコードによって表現されます。こうしたリソースは外部からは、YAML形式の(マニフェストと呼ばれる)テキストファイルで表現できます。リソースの望ましい状態を宣言するのがマニフェストです。
・kubectlはKubernetesを操作するための主要なツールで、マニフェストの適用、リソース情報の取得、変更の実施、リソースの削除、その他さまざまなタスクを実行できます。
・HelmはKubernetes用のパッケージマネージャです。Kubernetesアプリケーションの設定とデプロイを簡素化し、生のYAMLファイルをユーザ自身が保守しなくても、値の単一のセット(アプリケーション名や待ち受けるポートなど)やテンプレートのセットを用いてKubernetes用のYAMLファイルを生成できるようにします。

5章　リソースの管理
■まとめ
・KubernetesはCPUとメモリのリソースを、要求と制限に基づいてコンテナに割り当てます。
・コンテナの要求は、実行に必要となるリソースの最小量です。また制限は、リソースの使用が許される最大量を指定します。
・最小限のコンテナイメージは、ビルド、ブッシュ、デプロイ、起動が高速になります。コンテナが小さいほど、セキュリティ上の潜在的な脆弱性も少なくなります。
・Liveness probeは、コンテナが適切に機能しているかどうかをKubernetesに報告します。Liveness probeが失敗を返す場合、コンテナは終了および再起動されます。
・Readiness probeは、コンテナの準備が整ってリクエストに対応できることをKubernetesに報告します。Readiness probeが失敗を返す場合、コンテナは自分を参照している任意のServiceから取り除かれ、ユーザのトラフィックから切断されます。
・PodDisruptionBudgetsを使用すると、退去(eviction)処理の間に一度に停止できるPodの数を制限して、アプリケーションの高可用性を保持できます。
・Namespaceはクラスタを論理的にパーティション化する方法で、アプリケーション別や関連するアプリケーションのグループ別に作成できます。
・別のNamespaceにあるServiceを参照するには、DNSアドレスを使用できます(例:SERVICE.NAMESPACE)。
・ResourceQuotaを使用すると、与えられたNamespaceの総合的なリソース制限を設定できます。
・LimitRangeは、Namespace内のコンテナに適用されるデフォルトのリソース要求とリソース制限を指定します。
・リソース制限は、アプリケーションの通常の使用状況を少し上回る程度に設定します。
・必要以上に大量のクラウドストレージを割り当てることや、アプリケーションの処理能力にとって重要ではないかぎり、高帯域幅のストレージをプロビジョニングすることは避けます。
・すべてのリソースに所有者Annotationを設定し、クラスタを定期的にスキャンして所有者不明のリソースを特定します。
・使用されていないと思われるリソースを探し出してクリーンアップします(ただし所有者に確認します)。
・使用状況を長期的に計画できる場合には、リザーブドインスタンスを使用するとコストを削減できます。
・プリエンプティブインスタンスは即座にコスト削減効果を期待できますが、急に消滅する可能性に備える必要があります。障害を許容しないPodがプリエンプティブノードにスケジューリングされないようにするには、Node Affinityを使用します。

6章　クラスタの運用
■まとめ
・本番のKubernetesクラスタをプロビジョニングする前に、必要になるノードの数とサイズを検討します。
・少なくとも3つのマスタノード(マネージドサービスを利用する場合には不要)、および少なくとも2つ理想的には3つ)のワーカノードが必要です。この構成のKubernetesクラスタは、小さなワークロードを実行するだけの場合、最初はやや割高に思えるかもしれませんが、耐障害性とスケーリングが当初から組み込まれているメリットを忘れないでください。
・Kubernetesクラスタは、数千個のノードおよび十数万個のコンテナという規模にまで拡張可能です。
・これを超える規模に拡張する必要がある場合は、複数のクラスタを使用します(セキュリティやコンプライアンスの理由から、これが必要になる場合もあるでしょう)。クラスタ間でワークロードを複製する必要がある場合には、フェデレーション機能を使用してクラスタション機能を同期させることができます。
・Kubernetesノードの典型的なインスタンスサイズは、1CPUと4GiBのRAMです。とはいえ、2つや3つの異なるノードサイズを混在させるのも優れた方法です。
・Kubernetesはクラウド専用ではなく、ベアメタルサーバでも実行できます。物理マシンが余っているのであれば、Kubernetesで活用しない手はありません。
・クラスタは手作業で規模を拡大縮小しても、それほど大きな問題が生じることはなく、おそらくは頻繁に調整する必要もないでしょう。オートスケールは便利な機能ではありますが、それほど重要ではありません。
・Kubernetesのベンダと製品については、明確に定義された標準があります。つまり、CNCFのCertified Kubemetesマークです。これが表示されていない場合には、その理由を確認しましょう。
・カオステストは、Podをランダムに終了させ、その場合でもアプリケーションが機能するかを確認するプロセスです。 これは役に立ちますが､ クラウドにはいずれにしても、あなたが求めるまでもなく独自のカオステストを行う方法が用意されています。

7章　Kubernetesの強力なツール
■まとめ
・kubectlには、それ自身についても(kubectl -h)、Kubernetesのあらゆるリソース、フィールド、機能についても(kubectl explain)、完全かつ包括的なドキュメンテーショ ンが用意されています。
・kubectlの出力に関して、複雑なフィルタリングや変換を例えばスクリプト内で行いたい場合には、-o jsonでJSON形式を選択します。JSONデータが得られれば、jqのような強力なツールを使用してクエリが可能です。
・kubectlの--dry-runオプションを、YAML出力を得るための-o yamlと組み合わせると、命令的なコマンドを使用してKubernetesマニフェストのポイラプレートを生成できます。これは例えば新規アプリケーション用にマニフェストを作成する際に、時間の大幅な節約になります。
・kubectl getで--exportフラグを使用すると、既存のリソースをYAMLマニフェストに変換することもできます。
・kubectl diffでは、マニフェストを適用した場合に変わるであろう点を、実際には変更せずに確認できます。
・kubectl logsでは、任意のコンテナからの出力とエラーメッセージを表示でき、--followフラグで継続的にストリーミングすることもできます。 また、 Stern を使用すると、より洗練された複数Podログのフォローが可能です。
・コンテナの問題をトラブルシューティングするには、 kubectl attachによりコンテナにアタッチすることや、kubectl exec -it... /bin/shによりコンテナ上でシェルを使用することができます。
・kubectl run を使用すると、公開されている任意のコンテナイメージを実行して問題解決に役立てることができます。例えば、使い慣れたUnixコマンドがすべて含まれている、多機能なBusyBoxツールも利用できます。
・KubernetesのContextはブックマークのようなもので、特定のクラスタやNamespace内の場所をマーキングできます。kubectxおよびkubensツールを使用すれば、Context間やNamespace間で手軽に切り替えることができます。
・Clickは強力なKubernetesシェルで、kubectlのすべての機能を利用できるだけでなく、追加の状態もあります。つまり、コマンドが変わっても現在選択されているオブジェクトを記憶しているため、ユーザはその都度指定する必要がありません。
・Kubernetes はコードによって自動化および制御できるように設計されています。 kubectlが提供するものを超える機能が必要な場合には、Kubernetesのclient-goライブラリを使用すると、クラスタのあらゆる側面をGoコードによって完全に制御できます。

8章　コンテナの実行
■まとめ
・Linuxのコンテナとは、カーネルレベルではプロセスの分離されたセットであり、リソースがリングフェンスで囲い込まれています。コンテナの内部からは、コンテナ自体が1台のLinuxマシンを占有しているかのように見えます。
・コンテナは仮想マシンではありません。個々のコンテナは1つの主要な プロセスを実行する必要があります。
・Podには一般に、主要なアプリケーションを実行する1つのコンテナと、それをサポートするオプションのヘルパコンテナが(複数)含まれます。
・コンテナイメージの識別子には、レジストリホスト名、リポジトリ名前空間、イメージリオジトリ、タグを指定できます(例: docker.io/cloudnatived/demo: hello)。なお、メージリポジトリだけが必須です。
・デプロイの再現性を高めるためには、コンテナイメージの識別子に常にタグを指定します。これを省略すると、何であれたまたまlatestとタグ付けされているものを取得することになります。
・コンテナ内のプログラムをrootユーザとして実行してはなりません。その代わりに通常のユーザを割り当てます。
・コンテナにrunAsNonRoot: true フィールドを設定すると、rootとして実行することを要求するコンテナをブロックできます。
・コンテナのセキュリティ強化に役立つ他の設定としては、readOnlyRootFilesystem: true とallowPrivilegeEscalation: false があります。
・Linuxのケイパビリティは、きめ細かな権限制御機構を提供しますが、コンテナに設定されるデフォルトのケイバビリティは寛容すぎます。コンテナでは最初にすべてのケイバビティを削除してから、必要に応じて特定のケイバビリティを許可するようにします。
・同じPodを構成するコンテナは、マウントされたボリュームを読み書きすることによってデータを共有できます。最も単純なボリュームはemptyDirというタイプで、空の状態から使用が始まり、そのPodが実行されている間だけコンテンツを保持します。
・これに対してPersistentVolumeは、必要とされる限りの間ずっとコンテンツを保持します。PodはPersisitentVolumeClaimを用いて、新規のPersistentVolumeを動的にプロビジョニングすることもできます。

9章　Podの管理
■まとめ
・Labelとはリソースを識別するキーと値のペアであり、セレクタと組み合わせて使用すると、リソースの特定のグループに一致させることができます。
・Node Affinityは､指定された属性を持つノードにPodを引き寄せるか、そうしたノードからPodを遠ざけます。例えば、指定されたアベイラビリティゾーンに属するノードのみでPodを実行できるように設定できます。
・ハードNode AffinityはPodの実行を防ぐことができますが、ソフトNode Affinityは「可能であれば・･･･」とスケジューラに提案する感じになります。複数のソフトAffinityを組み合わせ、異なる重みを与えることができます。
・Pod AffinityはPodについて、他のPodと同じノードにスケジューリングするのが望ましい。という選好性を表現します。例えば、同じノードで実行されることがメリットになるPod同士は、Pod Affinityを用いて、そのことを相互に表現できます。
・Pod Anti-Affinityは、他のPodを引き寄せるのではなく遠ざけます。例えば、同じPodのレプリカに対してAnti-Affinityを設定すると、クラスタ全体にレプリカを均等に配置するのに役立ちます。
・Taintは、一般にノードの問題や障害に関する特定の情報でノードをタグ付けする方法です。デフォルトでは、Taintが設定されたノードにはPodがスケジューリングされません。
・Tolerationを使うと、特定のTaintが設定されたノードにPodをスケジューリングできます。この機構を利用すれば、特定のPodを専用ノード上だけで実行できるようになります。
・DaemonSetを使うと、Podの1つのコピーをすべてのノードにスケジューリングできます(例:ロギングエージェント)。
・StatefulSetはPodのレプリカを番号付きの特定の順序で起動および終了するため、個々のレプリカを予測可能なDNS名でアドレス指定できるようになります。これはデータベースな どのクラスタ化されたアプリケーションに理想的です。
・JobはPodを1回(または指定された回数)だけ実行したのち、完了となります。同様に、CronJobはPodを指定された時間に定期的に実行します。
・Horizontal Pod Autoscaler(HPA)は一連のPodを監視して、所定のメトリクス(例:CPU使用率)が最適化されるように試みます。つまり、指定された目標を達成するため、実行されるレプリカの望ましい数を増減させます。
・PodPresetでは、共通の設定情報をすべての選択されたPodの作成時に注入できます。例えば、PodPresetを用いて、特定のVolumeをすべての一致するPodにマウントすることが可能です。
・Custom Resource Definition(CRD)を使うと、例えば希望する任意のデータを保存するといった目的のために、独自のカスタムKubernetesオブジェクトを作成できます。Operatorは、特定のアプリケーション(例:MySQL)向けにオーケストレーションの機能を実装できるKubernetesクライアントプログラムです。
・Ingress リソースは、一連のルール(例:リクエストのURLの一致する部分)に基づいて、リクエストを異なるサービスにルーティングします。また、アプリケーション向けにTLS接続の終端処理を実行することもできます。
・Istioはマイクロサービスのアプリケーションに高度なネットワーキング機能を提供するツールで、他の Kubernetesアプリケーションと同様にHelmを用いてインストールできます。
・Envoy は標準のクラウド型ロードバランサよりも高度なロードバランシング機能を提供し、サービスメッシュにも対応できます。

10章　設定と機密情報
■まとめ
・設定データはアプリケーションのコードから分離し、KubernetesのConfigMapやSecretを用いてデプロイします。こうすることで、例えばパスワードを変更するたびにアプリケーションを再デプロイする必要がなくなります。
・ConfigMapにデータを取り込むには、Kubernetesのマニフェストファイルに直接記述する方法と、kubectlを用いて既存のYAMLファイルをConfig Mapに変換する方法があ ます。
・データを取り込んだConfigMapは、コンテナに環境変数挿入するか、コンテナのエントリポイントにコマンドライン引数として渡すことができます。また、データをファイルに書き込んでコンテナにマウントする方法もあります。
・Secretの使い方はConfigMapとほぼ同様ですが、保存データの暗号化(encryption at res)が有効な場合はデータが保存時に暗号化され、kubectlの出力では難読化される点が異なります。
・機密情報を管理するためのシンプルで柔軟な方法は、ソースコードのリポジトリ内に直接保存することですが､ SOPSなどテキストベースの暗号化ツールを使って暗号化する必要があります。
・機密情報管理については特に最初のうちは、あまり深刻に考えることはありません。開発者にとって容易にセットアップできるシンプルな方法から始めます。
・機密情報を多くのアプリケーションが共有する状況では、機密情報を(暗号化して)クラウドバケットに保存して、デプロイ時に取り出す方法が効果的です。
・大企業レベルの機密情報管理では、 Vaultなどの専用の機密情報管理ツールが必要になります。しかし、結局そこまでの必要性はなかったと後になって判明する可能性があるため、いきなり専用ツールから始めることは推奨しません。必要に応じて専用ツールに移行することはいつでも可能です。
・SOPSはYAMLやJSONなどキーと値のペアが記述されたファイルと組み合わせて活用できる暗号化ツールです。使用する暗号鍵は、ローカルに実行する GnuPGの鍵束(keyring)からも、Amazon KMSやGoogle Cloud KMSなどクラウドの鍵管理サービスからも取得できます。

11章　セキュリティとバックアップ
■まとめ
・ロールベースのアクセス制御(RBAC)を使用することで、Kubernetesにおけるパーミッションをきめ細かく管理できます。この機能が有効になっていることを必ず確認し、RBACロールを用いて、特定のユーザやアプリケーションには職務やジョブの実行に必要となる最小限の権限だけを許可します。
・コンテナだからといって、セキュリティやマルウェアの問題が魔法のように免除されるわけではありません。本番で実行するコンテナはすべて、スキャンツールを使ってチェックします。
・Kubernetesは安定性や可用性に関して極めて高いレベルにありますが、それでもバックアップは必要です。クラスタのデータと状態をバックアップするにはVeleroを使うとよいでしょう。これはクラスタ間でそれらを移行するのにも便利です。
・kubectlは、クラスタとそのワークロードをあらゆる側面から検査および報告できる強力なツールです。 kubectlは頻繁に使用して多くの時間を費やすことになるので、ぜひ使い方をマスタしましょう。
・クラスタの運用状況をグラフィカルな表示で概観するためには、KubernetesプロバイダのWebコンソールや、kube-ops-viewを使います。Kubernetes Dashboardを使う場合には、クラウド認証情報や暗号鍵の場合と全く同じレベルで厳格にセキュリティを確保する必要があります。

12章　Kubernetesアプリケーションのデプロイ
■まとめ
・チャートとはHelmパッケージの仕様で、パッケージに関するメタデータ、一部の設定値、設定値を参照するKubernetesオブジェクトのテンプレートが含まれます。
・チャートをインストールするとHelmリリースが作成されます。チャートのインスタンスをインストールするたびに新しいリリースが作成されます。異なる設定値でリリースを更新すると、Helmがリリースのリビジョン番号をインクリメントします。
・独自の要件に合わせてHelmチャートをカスタマイズするには、変更したい設定のみを上書きするカスタム値ファイルを作成して、helm installまたはhelm upgradeのコマンドラインに追加指定します。
・変数(例:environment)を使うと、ステージングや本番といったデプロイ環境に応じて、異なる一連の値や機密情報を選択できます。
・Helmfileを使うと、クラスタに適用する必要がある(複数の)Helmチャートや値を宣言的に指定でき、そのすべてを単一のコマンドでインストールまたは更新できます。
・HelmをSOPSと組み合わせて使うことで、チャート内の機密情報に関する設定を処理できます。また、関数を使って、機密情報を自動的に(Kubernetesが想定する形式の)base64でエンコードすることもできます。
・HelmはKubernetesマニフェストの管理に利用できる唯一のツールではありません。ksonnetとKapitanは、JSONとは異なるテンプレート作成言語であるJsonnetを使用しま す。kustomizeはアプローチが異なり、 変数を補完するのではなく、YAMLオーバレイのみを使ってマニフェストを設定します。
・マニフェストをすばやくテストおよび検証する方法はKubevalを使うことで、構文の有効性やマニフェストでありがちなエラーがチェックされます。

13章　開発ワークフロー
■まとめ
・Kubernetesにおけるデフォルトのデプロイ戦略であるRollingUpdateは、一度に少数のPodをアップグレードし、交換されるPodの準備が整うまで待ってから古いPodをシャットダウンします。
・ローリングアップデートは、ロールアウトの時間が長くなるという犠牲を払ってダウンタイムを回避します。また、ロールアウトの実行中は、アプリケーションの新旧バージョンが同時に実行されることにもなります。
・maxSurgeおよびmaxUnavailableフィールドの値を変更すると、ローリングアップデートの動作を微調整できます。なお、使用するKubernetes APIのパージョンによっては、デフォルト値がユーザにとって必ずしも適切であるとは限りません。
・Recreateは古いPodをすべて一斉に終了して、新しいPodをすべて一度に起動します。これはロールアウトが高速ですがダウンタイムが発生するため、ユーザからのリクエストに対応するアプリケーションには不適切です。
・ブルーグリーンデプロイでは、新しいPodがすべて起動されて準備が整っても、ユーザのトラフィックを受信しないまま待機します。その後、すべてのトラフィックを新しいPod群に一度に切り替えてから、古いPod群を引退させます。
・レインボーデプロイはブルーグリンデプロイと似ていますが、3つ以上のバージョンが同時に稼働されます。
・Kubernetesでブルーグリーンデプロイとレインボーデプロイを実装するには、PodのLabelを調整し､フロントエンドServiceのセレクタを変更することで、適切なPod群にトラフィックを振り向けます。
・Helmのフック機能は、特定のKubertetesリソース(一般にJob)の特定の段階で(例えばデータベースの移行を実行するために)適用する手段となります。フックを使えば、デプロイの進行中にリソースが適用される順序を定義することや、何らかの処理が失敗した場合にデプロイを停止させることもできます。

14章　Kubernetesにおける継続的デプロイ
■継続的デプロイとは何か
　継続的デプロイ(continuous deployment、CD)とは、成功したビルドを本番へ自動的にデプロイする仕組みです。テストスイートと同じく、デプロイも一元的かつ自動的に管理する必要があります。つまり開発者にとっては、ボタンを押す、マージリクエストをマージする、Gitリリースタグをプッシュするといった方法で新しいバージョンをデプロイできることが求められます。
　CDと関連付けられることが多い概念として継続的インテグレーション(continuous integration、CI)があります。これはメインライン(mainline)ブランチに対して開発者が行う変更の統合とテストを自動化する仕組みです。その基本的な考え方は、メインラインにマージされるとビルドを壊すであろう変更をブランチに加えている場合には、ブランチがメインラインにマージされるのを待って壊れたことに気付くのではなく、マージされる前に継続的インテグレーションが直ちに開発者に壊れていることを通知するというものです。継続的インテグレーションと継続的デプロイの組み合わせは多くの場合、CI/CDとして言及されます。
　継続的デプロイを実現する過程は、しばしばパイプラインと呼ばれます。つまり、開発者のワークステーションからコードを取り出し、テストと受け入れステージを経て本番へとデプロイする、一連の自動化されたアクションです。
　コンテナ化されたアプリケーションのための典型的なパイプラインは次のようなものとなるでしょう。
1. 開発者がコードの変更をGitリポジトリにプッシュ(アップロード)します。
2. ビルドシステムが最新のコードをビルドして、テストを実行します。
3. すべてのテストに成功すると、コンテナイメージがコンテナレジストリに対してパブリッシュされます。
4. 新たにビルドされたコンテナがステージング環境へ自動的にデプロイされます。
5. ステージング環境では、自動化された受け入れテストが実施されます。
6. 検証されたコンテナイメージが本番環境へデプロイされます。
　ここで重要なポイントは、さまざまな環境を通じたテストおよびデプロイの対象となるアーティファクト (成果物) がソースコードではなくコンテナであることです。ソースコードから実行可能なバイナリができるまでには、さまままな形でエラーの入り込む可能性があるものですが､ コードの代わりにコンテナをテストすれば、そうしたエラーの多くを捕捉して対応できるようになり ます。
　CDの大きなメリットは、本番で驚かないことです。つまり、ステージング段階でテストに成功 している完璧なバイナリイメージでなければ、本番にデプロイされることはありません。

■まとめ
・新しいパイプラインを構築する際には、使用するCDツールの決定が重要なプロセスとなります。本書を通じて言及している各種のツールはいずれも、既存のCDツールのほぼすべてに組み込める可能性が高いと思われます。
・Jenkins、GitLab、Drone、Cloud Build、Spinnakerは、広く普及していてKubernetesとの連携性にも優れたCDツールのごく一部にすぎません｡ また、Gitkube、Flux、Keelのように、Kubernetesクラスタへのデプロイの自動化に特化して開発された新世代ツールも続々と登場しています。
・ビルドパイプラインのステップをコードで定義すると、こうしたステップもアプリケーションコードと共に追跡および変更できます。
・開発者はコンテナを利用することで、ビルドのアーティファクトを複数の環境間で次々に渡していくことができます(例えば、テスト、ステージング、および最終的には本番)。理想的な状況では、新しいコンテナを再ビルドする必要もありません。
・Cloud Buildを使用する本書のパイプライン例は、他のツールや他のタイプのアプリケーションにも容易に適応化できるはずです。ビルド､ テスト､デプロイという全体的なステップ構成は、使用するツールにもソフトウェアのタイプにも関係なく、どのCDパイプラインでも基本的に同じです。

15章　オブザーバビリティと監視
■まとめ
・ブラックボックス型の監視チェックは、システムの挙動を外部から観察して予測可能な障害を検出します。
・分散システムでは、アップまたはダウンの状態を単純に区別できないため、従来型監視の限界が露呈します。つまり分散システムでは、サービスが部分的に劣化しているのが定常的な状態であって、それを前提として稼働します。言い換えると、船上では絶対的に正しいことなど何もないのです。
・ログはインシデント発生後のトラブルシューティングには役立ちますが、スケールが困難です。
・メトリクスは、動作している/動作していないという単純な判断を超えて新たな次元を切り開き、システムの数百あるいは数千もの側面について時系列に沿った継続的な数値データを与えてくれます。
・メトリクスはなぜかという疑問の解決に役立ち、問題がある傾向を全面的な機能停止に至る前に特定します。
・トレーシングは、個別のリクエストのライフサイクル全体を通じて正確なタイミングでイベントを記録し、性能の問題をデバッグするのに役立ちます。
・オブザーバビリティとは、従来の監視、ロギング、メトリクス、トレーシング、それにシステムを理解するために利用できる他の方法もすべて統合する概念です。
・オブザーバビリティに取り組むことは、事実とフィードバックに基づくエンジニアリングのチーム文化へと移行することになります。
・ユーザに対応するサービスについては、アップかどうかを外部からのブラックボックス型チェックで確認することがやはり重要です。しかし、独自の監視システムを構築しようとはせず、Uptime Robotなどサードパーティの監視サービスを活用します。
・ユーザがハッピーでないのなら、アップタイムを示す9の数に意味はありません。

16章　Kubernetesにおけるメトリクス
■まとめ
・重要なメトリクスに集中します。サービスの場合はリクエスト、エラー、持続期間(RED)、リソースの場合は使用率、飽和度、エラー(USE)です。
・アプリケーションにインストルメンテーション(測定装置を装備すること、計装)を追加して、内部オブザーバビリティとビジネスKPI、双方の目的のためにカスタムメトリクスを公開します。
・Kubernetesで役に立つメトリクスとしては、クラスタのレベルでは、ノード数、ノードあたりのPod数､ノードのリソース使用率があります。
・Deploymentのレベルでは、Deploymentの数とPodレプリカの数を追跡します。特に、利用できないレプリカ(Unavailable replicas)は、クラスタのキャパシティに関する問題を示している場合があります。
・コンテナのレベルでは、コンテナあたりのリソース使用率 Liveness/Readinessの状態、再起動回数、ネットワークトラフィック、ネットワークエラーを追跡します。
・すべてのサービスで標準レイアウトを用いてダッシュボードを構築し、またシステム全体のバイタルサインを報告する情報ラジエータも構築します。
・メトリクスに基づいてアラートを通知する場合は、 緊急かつ重要で対処可能なアラートに限定します。 アラートがノイズの場合は、疲労を増して士気を損ないます。
・チームが対応する(特に睡眠中や週末の)緊急呼び出しの回数を追跡およびレビューします。
・クラウドネイティブの世界で事実上の標準となっているメトリクス管理ソリューションがPrometheusであり、ほぼすべてのツールやサービスがPrometheusのデータ形式を理解できます。
・サードパーティのマネージドメトリクス管理サービスとしては、 Google Stackdriver、Amazon CloudWatch、Datadog、New Relicなどがあります。 (参考：楽天)

わかりやすい説明と順番に進めていくため、理解しやすかった。AWSに構築する以外にローカル環境での手順もあるとより良かったと思いました。 (参考：YahooShopping)

dockerの基礎から学べるので初学者にオススメ。
以前、別のdockerの書籍を読んだがそちらはかなり実践形式だったので基本的な知識から学べるこの本はよかった。
いまやwindows homeでdockerいじれるのでソフトのインストールとセットアップもだいぶハードル下がったよね。2年前にvirtual boxとか入れて必死にdocker使えるようにしてたの懐かしい〜笑
ただこの本はawsのサーバーを使いながら進めていくので手元のwindows pcでやるならWSL入れといた方が進めやすいと思います。
それにしてもいい加減awsいじれるようにならなくちゃ、、、 (参考：honto)

IT業界入りたて、Dockerって何？っていう人が読むような本ではなかったです。インフラ（仮想環境）をある程度知っている人でないとこの知識は身につかないかなと思います。

docker CE(community edition)とdockerEE(enterprise edition)はそれぞれ結構なページを割いて詳しく説明があり、このレベルの違いが知りたい人にとっては有意義な本なのかなと思います。

docker使ってなんかアプリ作ってみたいなレベルの人の実践ガイドでは無いかな。 (参考：楽天)