diaryクラウドで働くインフラエンジニアの日々の感想です(ほぼ毎日更新)。Kubernetes・コンテナ本を買いました昨日のKubernetesエントリーが好評なので続きます。一応記念写真を冒頭に置きました。頑張って半日で読みたい部分は読み終えました。この本は前半をしっかり読んで、後半はつまむ程度で十分です。OpenShiftにおけるKubernetesの扱いの紹介でした。OpenShiftの量が多く今のところ私には不要なので見ていません。AWSやAzureの記載がないというのも面白いところです。基本的にはGCPの記載を見ておけばどのクラウドでも様子はわかるでしょう。OpenShiftについてはちょっと毛色が違う話です。これはコンテナを使った企業の統合基盤を構築するミドルウェアです。オンプレにも構築でき、パブリッククラウドの仮想サーバー、VMwareの仮想基盤上にも構築できます。自力で企業の統合コンテナ基盤を作るためのソフトウェアです。Kubenetesについては「サポートする」のであり別のオーケストレーションも使えるという立てつけです(とはいえ今からKubernetes以外はないでしょうが)。Kubernetesばかりではないこの本をなぜ手に取ったかと言うと、前半が初心者の私にとても良かったからです。Mesosの話に膨らみ、Kubernetesに落ち着くまでの話が細かく書かれています。パブリッククラウドとDocker社との政治的な経緯も面白かったです。コンテナのオーケストラレーションがKubernetesにほぼ一本化されるまでの紆余曲折が知りたかったのでこのあたりに詳しいです。この本は字が小さいので内容がしっかり詰まっています。ハヅキルーペが欲しくなりそうでしたが数ページで目は慣れました。SwarmやMesosの話はあまり頭に入れなくていいと思います。Kubernetesと同じことがしたいのに言葉の定義が違うので混乱します。SwarmやMesosがうまくいかなかったことをKubernetesはかくもうまくやっているということを知るためのストーリーとしてよいと思います。SwarmなんてこれからKubernetesに寄せていくというのですから、Kurbernetesだけ学べば自然とSwarmもわかるようになるでしょう。この本の第一刷は2017年3月で第二刷が2018年7月、もう1年ちょっと経つのでもはや少し古めです。11人の方の共著でありまだ標準が定まらなかった中でいろいろなテーマが書かれているので今までの動きを知るためには良い本だと思います。一刷丸ごとKubernetesというわけではないので、もっと突っ込みたいときは別の本になると思います。するとリファレンス的なものとなってしまい一から十まで読んでも頭に入らないかもしれないので、読み物としては今のところこの本(特に前半)がお勧めです。第4章のKubernetesについては、スッキリまとまっています。私の断片的なKubernetesの基本的な部分がまとまりました。サブタイトルの「Docker/Kubernetesで作るクラウド時代のシステム基盤」は後から付けたのではないかなと思います。コンテナのオーケストラレーションにまつわるこれまでの経緯といろいろな話、くらいが正しいです。それを知りたかったので十分でした。したこと読んでいろいろと思ったことがあるので書き留めておきます。Kubernetes実行環境を整えるという意味でインフラエンジニアは必要アプリケーションはコンテナの形で抽象化され、コーディングからデプロイまでの期間は短縮されるのですが、ストレージ(永続化ボリューム)やノードの準備はインフラエンジニアが整える必要があります。整っていること前提に開発者が使うので、どうやって使うかリードしなくてはいけません。どんなKubernetes環境でも同じように動く、とは言いますが、そのためには各環境の違いをインフラ側で吸収してやる必要があります。オーケストラレーションのポリシーをどうするか。永続化ボリュームに何を使うか。クラスタ全体のサイジングをどうするか。ノードのスペックはどうするか。監視はバックアップは・・・。ネットワークやロードバランシング、セッションの固定、ルーティング・・。オンプレとの連携や遠隔とのデータのやりとり。インフラエンジニア不要論には絶対になりません。インフラ観点から理屈をわかって動かさないと本番サービスとして満たさなければいけない品質には到底なりません。このあたりはどんなにバージョンが高くなっても、コンセプトから考えてずっと同じだと思います。インフラエンジニアからKubenetesは向かっていかないと、開発者だけではどうにもならないのではと思いました(たまに両方できるスーパーマンはいらっしゃいますが・・)。Pod(コンテナが実行される環境)の中のコンテナはlocalhost:<port>で通信できる1つのPodの中には複数のコンテナが定義でき、コンテナが公開するポート番号はかぶってはいけません。その原則のもと、互いのコンテナ間はlocalhost:<port>で通信できるということがわかりました。Composeで複数のコンテナで協調して動かすのと同じ理屈です。Podに突っ込めば内部通信はそれで完結します。これは結構重要な概念だと思います。PodでPODを作ることの差がよくわかっていませんでした。説明している文章を始めて読んだので感動しました。Deploymentを使ってデプロイすれば、新しいバージョンのPODをリリースするときに、古いバージョンを残しつつ新しいバージョンもデプロイし、古いバージョンを少しずつ消しながら、最後は新しいバージョンだけにしていきます。これをローリングアップデートと言い、サービス無停止でコンテナを置き換えることができるようになります。Deploymentでデプロイした場合は、前のバージョンにロールバックもできます。上の逆をやるわけです。