本を買いました
昨日のKubernetesエントリーが好評なので続きます。
早速本を買ってきました。一応記念写真を冒頭に置きました。
本全体の感想
頑張って半日で読みたい部分は読み終えました。この本は前半をしっかり読んで、後半はつまむ程度で十分です。後半については、GCPとIBM Cloudと、Redhat OpenShiftにおけるKubernetesの扱いの紹介でした。特にOpenShiftの量が多く今のところ私には不要なので見ていません。
AWSやAzureの記載がないというのも面白いところです。ただ基本的にはGCPの記載を見ておけばどのクラウドでも様子はわかるでしょう。
OpenShiftについてはちょっと毛色が違う話です。これはコンテナを使った企業の統合基盤を構築するミドルウェアです。オンプレにも構築でき、パブリッククラウドの仮想サーバー、VMwareの仮想基盤上にも構築できます。自力で企業の統合コンテナ基盤を作るためのソフトウェアです。Kubenetesについては「サポートする」のであり別のオーケストレーションも使えるという立てつけです（とはいえ今からKubernetes以外はないでしょうが）。
Kubernetesばかりではないこの本をなぜ手に取ったかと言うと、前半が初心者の私にとても良かったからです。コンテナの仕組みの話からDockerの登場、そこからSwarmやApache 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>で通信できるということがわかりました。つまりDocker Composeで複数のコンテナで協調して動かすのと同じ理屈です。Podに突っ込めば内部通信はそれで完結します。
これは結構重要な概念だと思います。
deploymentの役割は、ローリングアップデート
本を読むまでは、kind: DeploymentでPODを作るのと、kind: PodでPODを作ることの差がよくわかっていませんでした。
ちゃんと説明している文章を始めて読んだので感動しました。
Deploymentを使ってデプロイすれば、新しいバージョンのPODをリリースするときに、古いバージョンを残しつつ新しいバージョンもデプロイし、古いバージョンを少しずつ消しながら、最後は新しいバージョンだけにしていきます。これをローリングアップデートと言い、サービス無停止でコンテナを置き換えることができるようになります。
また、Deploymentでデプロイした場合は、前のバージョンにロールバックもできます。上の逆をやるわけです。無停止です。すごい。
手作業でPodを消したり作ったりするより、Deploymentを使うべき名ことを知り目からウロコです。こんなことすらネットではピンと来ませんでしたね。
また、コンテナを置き換えたり負荷によってReplication（複製）のPod数をスケールアウトしたりと、思いのままですね。ノードをスケールアップするのもDeploymentを使えばサービス無停止が基本です。
External Serviceがすごい
Kubernetesのクラスターの外に、物理サーバーもしくは仮想サーバー、RDSなど、データベースの接続ポイントがあるとします。192.168.100.10:5432（PostgreSQLの場合）など。これをPodの中で、EndPointを定義し、Serviceとして宣言すると、localhost:5432でアクセスできるようになります。Podの中にPostgreSQLが現れたみたいになるのですがもっとすごくて、どのPodからも同じデータベースがつつけるようになるわけです。
これができると、データベースなどの一部はモノリシック（いわゆる仮想サーバーなどでの普通の構築）をしておいて、フロントのWEBAPだけKubernetesでオートスケールできることとなります。データベースを変えたいときはもう一台作って向き先を変えればいいわけで、Kubernetesだけで閉じなくていいのは非常に便利だと思いました（詳しく知りたい方は94ページ参照のこと）。
コンテナでアプリを作ると言っても、そこにデータベースのDNS名やIPアドレスをハードコーディングしていたらせっかくの可搬性が台無しです。コンテナにはlocalhost:5432と書いておいて、実はクラウドのDBと通信している。素敵。
死活管理も柔軟性が高い
Kubernetesの場合、コンテナ（実際はPOD）の複製の数が決めてあって、そのPODが不調の場合は別のノードで動かす、オートヒーリングが有名です。でも、「どうやって不調って決めるのよ」と思いませんでしたか？。例えばjavaは生きていてもOutOfMemoryかもしれません。
この条件って変えられるそうです。特定のTCPポートにセッションがはれるか、URLを叩いてRC=2xx/3xxか、コマンドを叩いてRC=0か、など自由自在。
また、デプロイなどのPODの切り替えの際、コンテナとしては起動しているけれども、中のjavaの起動処理が終わるまではサービス公開したくないというときも、条件を同じように変えられます。
本番を意識するとこのあたりの情報がとても大事だと思います。
アプリをデプロイしたら、503がしばらく出る・・。WEBから応答がないのにオートヒーリングしないとかね。
オートヒーリングとvMotionは全然違う
確かに誤解されがちかもしれません。Podの調子が悪いときに他の新しいPodを起動し、調子の悪いものを落とす。ノードが別に移るので、結果だけで見ればvSphere DRSのvMotionみたいですが、vMotionなんて高度なことはしていなくて、単に落として別で起動しているだけです。VMware HAとは少し似ているかもしれませんが。
いつか聞かれそうなのでメモ。
CronJOBは便利そう
一日に一度だけコンテナ（POD）を起動させて、バッチ処理してコンテナを落としたい、なんて言うニーズがあっても、バッチ用のコンテナを上記起動している設計が多いのではないでしょうか。
CronJOBがまさにこれに応えられそう。文中ではまだ機能途上とあり。気を付けながら今後興味を持っていきたいです。
JSON勉強したい
全部がYAML形式(JSON)のファイルで説明できることから、逆にYAML形式をどのように書くのが正解かをきちんと身に着ける必要を感じました。いちいち構文エラーを食らっているので生産性が悪いです。※GUIがあればそれで終わりかもしれませんが。
まとめ
がーっと本を読んだので得た知識について本エントリー上では全部はまとめきれないのですが、とりあえず私の頭の中はスッキリできました。もし、コンテナ関係でもやもやしている方は、本書のご一読をお勧めします。前半部分だけでしたら一日あれば読めます。逆に、まだ手を付けてもおらずDockerすら知らない人は、Dockerをまずじっくり触ることをお勧めします。いきなりKubernetesはありませんしできません。
この本にはそういえば、ログの話がないんですが、そのあたりの本に欠けている部分はネットで補完すればいいかなと思っています。
そのうちKubernetesそのものの本に手を出すか・・。
上記の本、迷ったんですが、まだ今は早いかなと思ってスキップしました。dockerは良くわかっていてオーケストラレーションの経緯は興味がなく、いきなりKubernetesの運用に向かいたい人はこちらがお勧めです（立ち読みした限りでは）。
そう言えば、下記の本も実は買っていまして。
コンテナだけではなく、サーバーレスでの開発の実際も含まれていまして、これを次は流し読みするつもりです（週末かな）。コンテナの全貌だけ追いかけても、もっと大きなテーマが見えずらいので、これで疑似体験するつもりです。
パラパラ見た感じだと、Spring BootでのRESTサービス、AWS Lambda、Heroku等が実際に使われているので開発者の気持ちになれるかなと。Dockerもありますし、まずはとにかく開発者目線で動かすところを見てみたい（いわゆる動機の部分）。コンテナ対サーバレスというのが本当に対立軸かというのを知りたいです。
全体がわかれば、細部の勉強はインターネットの記事の方が当たりも多いので、まずは全体を知る訓練を続けているところです。
