【読了】Kubernetes 入門 第1章
- 作者: Kelsey Hightower,Brendan Burns,Joe Beda,松浦隼人
- 出版社/メーカー: オライリージャパン
- 発売日: 2018/03/22
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
EKSがGAになる前に勉強しとく！
Kubernetesを使う利点
ベロシティ(速さ)
- CDに入れられるソフトウェアから、Webベースのサービスに移り変わりユーザーへ提供するスピードが速くなった
- 近年はスピードに加え可用性を求められ、常にサービスを提供していく必要がある
- Kubernetesとコンテナがあれば、これらを実現出来る
- これを実現するための核となるコンセプト
- イミュータブルであること
- 宣言的設定
- オンラインで自己回復するシステム
イミュータブル
- イミュータブルであることは分散システムを構築しやすい、ロールバックが容易
- ミュータブル：伝統的にシステムはミュータブル。既存のバイナリや設定ファイルを変更が積み重ねられる
- イミュータブル：一回のオペレーションでイメージを更新する、既存のものを変更するのではなく新しく入れ替える
宣言的設定
- Kubernetes上はすべて宣言的設定のオブジェクト
- 宣言的なため、設定間違いが起こりにくい、ソースコード管理ができレビューやテストをしやすい
- 宣言的設定(declarative)：状態を定義する(Ansibleやコンテナのように状態を定義)
- 命令的設定(imperative)：命令的なコマンドの羅列によって状態を定義する(古くからある手順書による設定)
- 例：あるソフトウェアのレプリカを3つ起動するとき
- 宣言的設定：レプリカ数を3にする
- 命令的設定：Aを起動し、Bを起動し、Cを起動する
- 昔ながらの切り戻し手順考えて頑張ってた世界がかなり簡単で完全にロールバックできるようになる
自己回復するシステム
- 旧来であれば命令的なので、障害はアラートで通知され、オペレーターが手順に従い復旧を行う
- Kubernetesは宣言的設定になり、その状態は継続的に保たれる。障害が起きても宣言的設定に従い、状態を回復すり。AWSでいう、AutoScalingのイメージ。
- オペレータが介在しないので、確実で素早く、コスト効率のよいシステムを運用できる
サービスとチームのスケール
分離
- 分離し境界を設けることで、チームのスケールとインフラリソースのスケールが容易になる
- 各コンポーネントの分離：各コンポーネントはAPIで分離
- チームの境界が明確になる
- コンポーネント単位でのスケールが可能になる
- インフラの分離：インフラはロードバランサとコンテナによる分離
- 各チームがインフラの競合を意識せずに、アプリケーションをデプロイできる
- スケールがしやすい
アプリケーションとクラスタの簡単なスケール
- コンテナのスケールはイミュータブルかつ宣言的設定なので容易
- クラスタのスケールも、コンテナによるインフラの分離がされているので、インスタンスをクラスタに追加するだけ
- 複数のアプリを同じインスタンスで共有できるので効率が良い
マイクロサービスによる開発チームのスケール
- チームの人数は2枚のピザ。ただ開発規模との兼ね合いで人数が必要だったりする。これはマイクロサービスによる複数チームによる開発で解決する
- Kubernetesはマイクロサービス開発を容易にする、抽象化層やAPIを提供する
インフラの抽象化
- インフラ管理とアプリケーション管理を分離できるので効率的
効率性
- 1つのサーバーに複数アプリを依存なく、効率的に起動できる、集約できる
