Kubernetes
https://gyazo.com/69f90ad5d78474992e3772219f3bb32a
Kubernetes provides a container-centric management environment. It orchestrates computing, networking, and storage infrastructure on behalf of user workloads.
@k_bigwheel: 昨日、会社の後輩にkubernetesのなにがすごいのか説明していた。kubernetesの革新の本質は、表層的なコンテナオーケストレーションではない。それならECSやdocker swarmもやっていた。 @k_bigwheel: Kubernetesが本当にすごいのはInfrastructure as Definitionを実現したところ。 ほぼここに書いてあるようなことでこれはECSもSwarmもTerraformもできなかった革新的な考え方だった。
GoogleはBorgの実績があったのでこの方向で行けることがわかっていたという指摘 @k_bigwheel: しかもその優位性がソフトウェアの基本設計・思想という極めて変えづらいところにあったため、swarmやECSが気づいた頃にはどれだけリソースを追加しても追いつけないほど引き離されていたというわけ。 Kubernetes以前の自動化ではコマンドラインツールを書くバッチスクリプトを書くもしくはAnsibleのplaybookやChefのRecipeを書くといった手法が使われてきた．Kubernetesが当たり前になってからは長らくそれらをやっていないし問題の解法として頭に浮かばなくなった（むしろ避けている）．コマンドラインツールを書くのは好きだったが最近はめっきり書かなくなった． Ansibleとかを使っているが宣言的にはできないので大変kadoyau.icon
状態を記述したらその通りになる
この安定性がLevel triggeringで担保されている
学習リソース
Kubernetes がどのように、人間の作業を自動化しているのかを、実際にKubernetes がやっている作業を手作業で行なうことで学びましょう
この資料は「Kubernetes という名前ぐらいは知っているけど、実際には使ったことがない、何ができるのかよく知らない」という人を対象に、Kubernetes の基本的な使い方を説明しています。 この資料を読めば、Kubernetes 上に単純な Web アプリケーションをデプロイできるようになるはずです。
この文書はアプリケーション開発者を主なターゲットとしています。Kubernetes クラスタの構築・運用については扱いません。
OS がハードウェアとソフトウェアを疎結合にしたように、Kubernetes はアプリケーションとサーバーを疎結合にし、独立して開発・運用ができるようにしてくれます。
Kubernetes を導入しても物理サーバーの障害やメンテナンスをなくすことはできません。 障害やメンテナンスによってアプリケーションに影響が生じうるという事実も変わりません。
今までと何が違うのかというと、アプリケーションが障害・メンテナンスのハンドリングを Kubernetes の抽象レイヤーを通じて行えることです。 Kubernetes にはアプリケーションが障害から回復するために必要な道具がそろっているため、生で障害のハンドリングを行うよりもずっと楽ですし、サーバーの実装に直接依存しないのでサーバー側の変化にも影響されません。
ここ最新導入されたKubernetesの新機能や特徴を紹介するとともに、導入ツール「kubeadm」による最新版Kubernetesの環境構築方法を紹介する。
インタラクティブなチュートリアルがあり、図もわかりやすいのでまずこれをよむのがよさそうkadoyau.icon
本連載では、Kubernetesを触ったことがない方でもKubernetesのコンセプトを理解し、実際にアプリケーションをコンテナ化して実行することが出来るようになることを目標
5種類のリソースを解説
https://www.youtube.com/watch?v=QEu6dpQnJ7A
実践
Macで利用する
ローカル環境で利用する
ホスティング
Custom controllerがかける
サービスの移行事例
つらみ
最低構成で5台から
master 3
worker 2(1ならk8s使う意味なし）
managedサービスを使えばこの辺りは解決できるが、ベンダーロックインになる
「じゃあECSの方が使いやすくない？」
やれることが多い=学ぶことが多い
頻繁にアップデート=学習が必要
1年前の記事のコピペじゃ動かない
著者はドリコムのインフラエンジニア
研究開発としてはいったんやめました、また採用を視野に入れる可能性はあります
1つの大きなサービスに長く注力するならともかく、複数の小～中規模のサービスに適用していき、それぞれの部署で汎用的に運用できるようにしていく── そんなイメージは、触り始めた最初から最後まで持てませんでした。
著者の立場
オンプレ・クラウドへと地道にインフラに関与してきてエンジニア
複数サービスの面倒を見ることが前提になると、これらを崩すことは既存サービスとの大きな差分が発生し、運用コストが増加することは目に見えているので、できるだけクラウドの構成を保ちつつ Kubernetes を稼働させようとする
Kuberneteに寄せる気が限りなく薄い
k8sは使える
私のところの場合、複数のWEBサービスを提供することが主な目的になりますので、１サービス１アカウント（GCPの場合１プロジェクト）で、WEB・DB・KVSを基本として、必要ならクラウド特有のサービスも利用する、という感じでベースとなるインフラを用意・提供するわけです。
そういう条件下において、(1)従来のインスタンス構成 (2)ECSなど独自コンテナ (3)マネージドKubernetes でやってみた時にどうなるか、というと……新しいシステムほど怪しい部分はあるものの、どれも概ね要件を満たして構築はできるのです。
最大の特徴は抽象化
どの環境でもリソース種別ごとの扱い方は等しいし、クラスタ配下の扱いはその世界に閉じている。それによって、オンプレミス⇔クラウド や クラウドA⇔クラウドB そしてマルチクラウドまで視野に入れた動向があり、外殻的にも内部的にも流動性が高い
でもこのレイヤーの抽象化は（高い学習コストを払ってまで）必要ないのではないか？
普通のサービスが別リージョン・別クラウドでほしいシチュエーションは限定的
バックアップ
別クラウド特有のシステムを使いたい
1つのクラウドを使いこなすほうが効率がいい
1つのクラウドでやるなら抽象化レイヤーの必要性は薄まる
高い学習コスト
クラウドのマネージドになると、Kubernetes 自体の学習量はコントロールプレーンの分が減少するものの、抽象化して扱われる各クラウドリソースについて学習しなくてよいかというと、そんなわけもなく、特徴や関連性について学習することになるため、はいポチりましたで終わるものではありません。
仮にEKSをマスターしたからといって、GKEもすぐ動かせられるかというとそんなことはなく、周辺リソースとKubernetesクラスタの差分について学習する必要があります。 「使ってみたい」パワーは成果に繋がりやすいので、Kubernetes ほど知名度と情報があるシステムなら、担当者が使いたいって言ったら、それで行けばいいかって時も絶対あるんですよ。
エンジニアは結構、面倒くさい感じにモチベと成果が結びつきやすい人種なので、組織の規模が小さめのうちは、好き嫌いでの判断って結構しっくりきたりするんですよね。