Kubernetes
https://gyazo.com/661c2aa488da22a7db8f5b2414054e56
所感
まだ冒頭を読んだだけなので、間違いがあるかもしれないがイメージは以下のような感じ。
https://gyazo.com/21de49c2c4414e6da688460e20601e28
分散アプリケーションを作成、デプロイ、管理するためのプラットフォーム
入門
達成したいシステム要件
高信頼性 一部がクラッシュしても全体は継続できる
スケーラビリティ 大規模化が容易
高可用性 メンテやデプロイを無停止で行う
コンテナ API を利用する理由
Velocity
Scale
インフラの抽象化
効率性
Velocity
k8s のコンセプト
Immutability 状態を持たないので、常に Blue Green Deploy できる
Declalirive configuration 命令的でない。状態を記述するとそれを k8s が実現してくれる。素早くロールバックできる
Online self-healing system 宣言された状態に保つので、オペレーションやメンテのリソースを開発に回せる
Scale
コンポーネント間を分離する、分離アーキテクチャ を採用すると、コンポーネント自体を、技術的にも開発単位的にもスケールさせやすくなる。例えば、API でサーバとクライアントを分離した場合や、マイクロサービス同士をロードバランサで分離した場合が挙げられる。
https://gyazo.com/79f25d58ccafc7e3651ca25d6eaee591
例えば、Service A と Service B があった時、各々を独立してスケーリングさせる場合には、各々別々に分析してマシンの数や余剰なマシンの数を決定する必要がある。これが、k8s を利用すると、k8s が中間層になり、複数のサービスを同時にスケールさせやすいし、余剰なマシンの数も減らすことができる。
https://gyazo.com/774b6af81afc7824b9eff1d1616b4e98https://gyazo.com/93debf799d921fc285573510d633cb45
また、上図の下層にあたる k8s のクラスター自体の垂直スケーリングは簡単。マシンの上では Container が中間層となっているためにアプリケーションとマシンの依存関係がなくなっているので、クラスターをスケールさせたいなら、単純にマシンイメージを１つ作って追加するだけでよい。
https://gyazo.com/1e5c8fe2384406db66f35f513ec243dc
k8s を利用することで、担当するチーム (SRE) 毎に責務を分離できる。クラスタを提供する SRE は、その API の SLA を満たすことに集中しさえすればよく、アプリケーション開発者はその SLA が満たされている前提で開発を進めればよい。同様に、OS やカーネル等の低レイヤー層を専門とする SRE チームが、OS およびカーネルを提供する。その際にも SLA を提示し、クラスタを提供する SRE は、その OS やカーネルの SLA が満たされている前提でクラスタの設計を行えば良い。 https://gyazo.com/a9c5fbf3379c9d394589508c0819757e
インフラの抽象化
クラウド API は IT インフラを反映している
アプリケーションのポータビリティをあげる
クラウドプロバイダの機能の抽象化層として働く
特定マシンからアプリケーションを分離できる
特定のクラウド機能を抽象化するのでポータビリティが高まる
効率性
サーバの稼働コスト
CPU のアイドル時間は金の無駄
システム管理者が使用率を一定に保つのも大変
k8s はこれを効率よく管理する
個人毎にテストクラスタを効率的につくれる
一つのクラスタを複数人で共有できる
管理の人的コスト