Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
I will tell you the passion of Kubernetes
shogomuranushi
November 03, 2018
Technology
2
650
I will tell you the passion of Kubernetes
shogomuranushi
November 03, 2018
Tweet
Share
More Decks by shogomuranushi
See All by shogomuranushi
FPが教える iDeCo のすごさ
shogomuranushi
0
35
AWS Control Tower導入してハッピーになりました
shogomuranushi
0
51
EKS を使ってる人から見た App Runner
shogomuranushi
7
2.1k
Suggested Topicの質問に可能な限り答えてみた
shogomuranushi
0
940
顧客のアプリケーションコードが動くマルチテナント環境における課題とEKSにたどり着くまで
shogomuranushi
0
1.2k
ちょいテク100本ノック。できるまで帰しません 。今から使えるちょいテク集
shogomuranushi
1
1.6k
after of Infrastructure-as-Code-is-very-tired
shogomuranushi
16
3.2k
what is Cloud Run?
shogomuranushi
2
84
登壇資料_JAWS-UG_初心者支部_20190417.pdf
shogomuranushi
0
490
Other Decks in Technology
See All in Technology
疎ベクトル検索と密ベクトル検索: 第68回 Machine Learning 15minutes! Broadcast
keyakkie
1
250
大声で伝えたい!定時に帰る方法
sbtechnight
0
230
今 SLI/SLO の監視をするなら Sloth が良さそうという話
shotakitazawa
1
280
Simplify Cloud Native Security with Trivy
knqyf263
0
560
ECS Exec を使った ECS の トラブルシューティング
dohara
0
130
プロダクトマネージャーの役割と育成、評価
middleokada
16
11k
GCCP Creator @ COSCUP 2022
line_developers_tw
PRO
0
1.4k
Backlog × RPAでいろいろ捗った話
z_tetsu
0
380
データ分析のためのAWS Well-Architected -Data Analytics Lens-
maru1981
0
230
セキュキャンを卒業してその後
kurochan
0
570
私のAWS愛を聞け! ~ここが好きだよStep Functions~ #devio2022
kongmingstrap
0
290
第22回 MLOps 勉強会:みてねのMLOps事情
tonouchi510
1
930
Featured
See All Featured
4 Signs Your Business is Dying
shpigford
169
20k
Rails Girls Zürich Keynote
gr2m
87
12k
We Have a Design System, Now What?
morganepeng
35
3k
jQuery: Nuts, Bolts and Bling
dougneiner
56
6.4k
No one is an island. Learnings from fostering a developers community.
thoeni
9
1.3k
How New CSS Is Changing Everything About Graphic Design on the Web
jensimmons
213
11k
From Idea to $5000 a Month in 5 Months
shpigford
373
44k
Clear Off the Table
cherdarchuk
79
290k
Three Pipe Problems
jasonvnalue
89
8.7k
What’s in a name? Adding method to the madness
productmarketing
11
1.6k
Six Lessons from altMBA
skipperchong
14
1.4k
How to train your dragon (web standard)
notwaldorf
60
3.9k
Transcript
JAWS FESTA OSAKA 2018/10/26 ABEJA, Inc. Shogo Muranushi Kubernetes界隈のPassionate(熱量)伝えます
2
3
4 略歴トピック • インフラエンジニア • AWSを採⽤しハマる • AWSをたくさん使う • 資格を5冠取得
• AWSでDeepLearning プラットフォーム作る • インフラ => SRE Tech Lead • マイクロサービスで遊ぶ • プロダクトオーナーになる
5 アジェンダ 1. Dockerとは 2. Dockerオーケストレーションツール云々 3. Kubernetesについて
6 まずは質問 •Docker使ったことある⼈? •KubernetesやECSのようなサービス・ツール使ったこ とある⼈?
7 今⽇のゴール
8
9 •Dockerとは •Dockerの歴史 •なぜDockerを使うのか •Dockerを本番運⽤する上で何が課題になるのか
• 2013年リリース • コンテナ型仮想環境を提供 • コンテナにアプリケーションを内包させる • LinuxコンテナやWindowsコンテナあり • 様々なインフラやOSで動作
10 とは
11 の歴史 • 2013年 • dotCloudがOSSで公開 • 2014年 • Googleは毎週20億のコンテナを起動していた
• 1.0リリース • 2015年 • マイクロソフト、Google、Red Hat、VMware、Amazon Web Servicesらと共同でコン テナの標準化団体「Open Container Initiative」の発⾜ • (2011年) • Heroku エンジニアが The Twelve-Factor App を提唱 出展元:https://www.sdxcentral.com/cloud/containers/definitions/containers-vs-vms/
12 The Twelve-Factor App (2011) Webアプリケーションを使いやすい形でスケーラブルにするための⽅法論 • I. コードベース •
バージョン管理されている1つのコードベースと複数のデプロイ • II. 依存関係 • 依存関係を明⽰的に宣⾔し分離する • III. 設定 • 設定を環境変数に格納する • IV. バックエンドサービス • バックエンドサービスをアタッチされたリソースとして扱う • V. ビルド、リリース、実⾏ • ビルド、リリース、実⾏の3つのステージを厳密に分離する • VI. プロセス • アプリケーションを1つもしくは複数のステートレスなプロセスとして実⾏する
13 • VII. ポートバインディング • ポートバインディングを通してサービスを公開する • VIII. 並⾏性 •
プロセスモデルによってスケールアウトする • IX. 廃棄容易性 • ⾼速な起動とグレースフルシャットダウンで堅牢性を最⼤化する • X. 開発/本番⼀致 • 開発、ステージング、本番環境をできるだけ⼀致させた状態を保つ • XI. ログ • ログをイベントストリームとして扱う • XII. 管理プロセス • 管理タスクを1回限りのプロセスとして実⾏する The Twelve-Factor App (2011) Webアプリケーションを使いやすい形でスケーラブルにするための⽅法論
14 なぜDockerを使うのか • リソース集約効率が上がる • 必要な⾔語やライブラリを閉じ込めるため、 ⼀つのサーバで複数の⾔語やバージョンを稼働させられる • 複数環境載せてもセキュリティ上分離可能(厳密には・・) •
環境の再現性が⾼い • アプリの実⾏環境構築が容易で、構築⾃体や問題発⽣の再現性が⾼い • ポータビリティ性が⾼い • どの環境でも動かすことが可能で、移⾏や複数環境構築が容易 • ローカルと本番の環境を限りなく合わせることも可能で、開発・テストが容易
15 Dockerを本番運⽤する上で何が課題になるのか • 複数コンテナの管理 • 本番利⽤するときは1コンテナではなくWeb、App、DBなど複数 コンテナ • 可⽤性 •
正しく稼働していること、⾃動でリカバリすること • オートスケール • 負荷に応じて⾃動でスケールすること • モニタリング、セキュリティ、etc • それらを管理するツールが必要になってきた
16 オーケストレーションツール
17 以下の課題を解決 • 複数コンテナの管理 • 本番利⽤するときは1コンテナじゃなく複数コンテナ • Web、App、DBなど種類も複数 • 可⽤性
• 正しく稼働していること、⾃動でリカバリすること • オートスケール • 負荷に応じて⾃動でスケールすること • モニタリング、etc • それらを管理するツールが必要になってきた
18 オーケストレーションツールの歴史 • 2014 • GoogleがKubernetes、DockerがDocker swarm、AWSがECSを発表 • Mesos 0.21、Rancher
0.4リリース • 2015 • Docker swarm、Kubernetes 1.0リリース • CNCF(Cloud Native Computing Foundation)設⽴ • 2016 • Apache Mesos1.0 + Dockerサポート • Rancher1.0リリース
19 オーケストレーションツールの歴史 • 2017 • Fortune 100企業のKubernetesの採⽤率は54%を突破と報道(Redmonk) • DockerがKubernetesの統合を発表 •
Azure、AWSもKubernetesマネージドサービス提供 • 2018 • Rancher2.0リリース + Kubernetesを標準に
20 なぜKubernetesがデファクトスタンダードになったのか • 定期的なメジャーアップデート • 3ヶ⽉ごとにアップデートを繰り返し、エンタープライズからのフィードバックも反 映。本番稼働に耐えうるソフトウェアとして信頼を得た。 • によるエコシステムの拡⼤ •
Kubernetesの成⻑と共にCNCFに各⼤⼿企業が参加 • Alibaba、AWS、Google、IBM、Microsoft、Oracle、Redhat、VMware、etc • 様々な良質なOSSがCNCFのエコシステムに • Prometheus、Fluentd、GRPC、containerd、cni、envoy、helm、etc • その他の要素含め、これらにより企業と開発者が集まるサイクルができて、圧倒的な速度 で成⻑を遂げた
21 と、⾔われていますが個⼈的には • 設計がイマドキ • ベストプラクティスに添えば、良い設計になる • エコシステムのOSSもセンスが良い • Istio(Envoy)、Kubeflow、Knative、etc
• マイクロサービスの課題を解決しやすい • UNIXの哲学、The Twelve-Factor App、コンテナデザインパターンを採⽤ • マイクロコンテナになる • マイクロサービス化していく • マイクロサービスの管理⾟い • Istio登場 <<=== イマココ
22 Kubernetesは完璧か?使いこなすには? • Kubernetesは銀の弾丸ではない • マイクロサービスに耐えうる組織設計と⽂化形成と相性が良い(メルカリさん) • 組織設計 = コンウェイの法則
• ⽂化形成 = 価値提供の速度向上・⽣産性向上を徹底する⽂化 • ただし、マイクロサービスには課題がある • 分散システムのトレーシング、多数のシステム管理、⼀貫性、テスト、、、 • 完璧ではないけど、徐々に良い⽅向に向かっています • コンウェイの法則 • 組織の設計するシステムは、その組織のコミュニケーション構造をそのまま反映した設計になる
23 は? • ECSは良い⼦です • うちのシステムの8割はECSで動いています • Kubernetesは学習コスト⾼い。ECSはシンプルで簡単。マスター管理不要 • まず使ってみるには超オススメ
• Fargateは⾼いし制限はあるが、EC2が不要なのでかなり楽になる • しかし • ある程度運⽤していくと⾊々⾜りないことに気付く • ECSとAutoScaleの溝 => Spotinstを使って埋めよう • エコシステムがKubernetesに⽐べて弱い
24 使うならSpotinstは絶対オススメ
25
26 は何ができるのか • 複数のKubernetes Nodeの管理 • コンテナのスケジューリング • ローリングアップデート •
オートスケーリング • コンテナの死活監視 • 障害時のセルフヒーリング • サービスディスカバリ • ロードバランシング • ワークロードの管理 • ログの管理 • Infrastructure as Code • その他エコシステムとの連携や拡張 • ネットワークセキュリティ • モニタリング • 分散トレース • サービスメッシュ
27 を使うには? • マネージドサービス • AWS EKS、Google / GKE、Azure
/ AKS • ⾃前で作る • kubeadm、kube-aws、rancher、etc • 簡易に試す • minikube、Docker on Mac
28 Kubernetesの⾯⽩いと思うところ掻い摘み • いわゆるコンテナオーケストレーションに関する部分はパスします • ⾯⽩いと思うところ • UNIXの哲学、The Twelve-Factor App、コンテナデザインパターンを踏襲しやすい
• Kubernetesの実装内容が最新技術の勉強になる • 宣⾔型アーキテクチャ • エコシステムが盛り上がっていて、最新の課題に対するアプローチやコンセプトが勉強 になる • マイクロサービスの課題に対してIstio、サーバレスの課題に対してKnativeなど
29 Design patterns for container-based distributed systems
30 Design patterns for container-based distributed systems • 2016年に USENIX
Conference で発表された論⽂ • Single-container management patterns(コンテナ管理⽤の単⼀コンテナパターン) • Single-node, multi-container application patterns(シングルノードでのマルチコンテナパターン) • Sidecar pattern(サイドカーパターン) • Ambassador pattern(アンバサダーパターン) • Adapter pattern(アダプターパターン) • Multi-node application patterns(分散システムのためのマルチノードでのパターン) • Leader election pattern(リーダー選出パターン) • Work queue pattern(ワークキューパターン) • Scatter/gather pattern(スキャッター/ギャザーパターン)
31 Sidecar pattern(サイドカーパターン) • メインコンテナの横に配置 • 例)Webサーバをメインコンテナとして配置し、サイドカーとしてホスト側のログを保存 するコンテナを配置する(Fluentdなど) • メリット
• 開発の責任を分けやすくなり、独⽴してテストできる • サイドカーが異常になった場合にメインコンテナに 影響しない。ロールバックも個別に可能 • メインコンテナに CPUを優先的に割り当て、 サイドカーコンテナは空いた時間で処理する 出展元:https://qiita.com/MahoTakara/items/03fc0afe29379026c1f3
32 Ambassador pattern(アンバサダーパターン) • メインコンテナが外部とコミュニケーションをするときのプロキシになる • 例)Memcached や Redis のシャーディング⽤のツールとして利⽤される
twemproxy など • そのうち Kafka / AWS Kinesis / Google Cloud PubSub などを抽象化するパターンもあるかも • メリット • 開発者は外部とコミュニケーションをする という関⼼事をアンバサダーにオフロード できる(今回の例ではシャーディング) 出展元:https://qiita.com/MahoTakara/items/03fc0afe29379026c1f3
33 Adapter pattern(アダプターパターン) • アンバサダーとは異なり、外部とのインターフェースを標準化する • 例)システム内の全てのコンテナが同じモニタリングインターフェースを持つ • 今回の場合はモニタリングの共通I/Fに対応するためのアダプタコンテナを⽤意。アダプタ コンテナで各アプリケーションの仕様を抽象化
出展元:https://qiita.com/MahoTakara/items/03fc0afe29379026c1f3
34 Kubernetesの⾯⽩い実装 宣⾔型アーキテクチャ
Kubernetesの⾯⽩い実装:宣⾔型アーキテクチャ kubectl apply -f nginx.yaml kube-apiserver etcd apiVersion: v1 kind:
Pod metadata: name: nginx spec: nodeName: “” containers: - name: nginx-container 1) kube-apiserverにリクエスト 2) etcdにnodeNameが無い状態で書き込み
Kubernetesの⾯⽩い実装:宣⾔型アーキテクチャ kubectl apply -f nginx.yaml kube-apiserver etcd apiVersion: v1 kind:
Pod metadata: name: nginx spec: nodeName: “nodeA” containers: - name: nginx-container kube-scheduler 3) nodeName未割り当てを探して割り当て
Kubernetesの⾯⽩い実装:宣⾔型アーキテクチャ kubectl apply -f nginx.yaml kube-apiserver etcd apiVersion: v1 kind:
Pod metadata: name: nginx spec: nodeName: “nodeA” containers: - name: nginx-container 4) nodeNameが⾃分⾃⾝に割り当てられ ているPodがあれば、そのPodを起動する 37 kubelet In Server kubelet In Server kubelet In Server
38 Kubernetes エコシステム
39
40 とは • 2017年3⽉にOSSとして公開、2017年12⽉に⼀躍時の⼈に、2018年7⽉にGA、12,000 star • コアの部分はLyft社が開発したEnvoyに、EnvoyをマネジメントするためにIstioを開発 • マイクロサービスの課題を解決するために⽣まれたサービスメッシュであるIstio •
負荷分散と特定バージョンへの安全なルーティング • 多様な⾔語で実装、分散システムのネットワーク越しでのエラーハンドリング • どのシステムで遅延しているのか、状況はどうなのか、どこで何が起こったのか • サービス間の認証認可 • サイドカープロキシとして、コンテナのProxyとして実装
41 サービスメッシュ 出展元:https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh
42 の主な機能 • HTTP、gRPC、TCPのトラフィックに対する⾃動的なロードバランスとヘルスチェック • 豊富なルーティングルール • カナリアリリース、Blue/Green、A/Bテスト • トラフィックコントロール
• タイムアウト、リトライ、サーキットブレーカー、フォルトインジェクション • 各種メトリクスの収集と分散トレーシング • トラフィックの暗号化、サービス同⼠の認証および認可 出展元:https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh
43 のエコシステム
44
45 とは • 2017年12⽉にGoogleがKubeconで発表 • 2018年5⽉にOSSで0.1を公開、現在は0.3、2018年12⽉にGA予定、4,700 star • Kubernetesのクラスターの上で機械学習のジョブを動かせる •
機械学習のジョブをコラボレーションと対話により訓練するJupyter Hubや、Tensorflow の訓練とホスティングなどが含まれる • まだ発展途上だが注⽬度が⾮常に⾼い
46
47
48 とは • プロダクト名は「Knative」 • 2018年7⽉にGoogleが「現代的なサーバレスワークロードを構築、デプロイ、管理するた めの、Kubernetesベースのプラットフォーム」として公開 • まだまだベータレベル •
Kubernetes上でServerlessを実現するプロダクト • KubernetesでServerlessって、それServerlessじゃなくね・・?
49 個⼈的⾒解 • Googleはオープン戦略をとっている?(というよりCNCFが標準化思考)
50 結果 • みんなが集まる • さらに良いプロダクトが⽣まれる • Istio、Kubeflow、Knative、etc • より便利になる
• • みんなが集まる • さらに良いプロダクトが⽣まれる • より便利になる •
51 今後どうなるか • 流⾏り廃りが激しいし数年後にはKubernetesに代わる何かが出てるかも • コンテナは古くなってサーバレスが主流になってるかも • でも、流⾏りの技術を通して業界の課題や解決⼿法のアプローチ、業界の流れが⾒えてくる • 概念やコンセプトは⾮常に参考になるし、⾃分の設計に活きてくる
• ということで、Kubernetes始めてみませんか?
52 Tokyoリージョンまだ?!
53 個⼈にとってKubernetesを学ぶと何が良いのか • 最新のコンセプトや概念を学べる • 命令型ではなく宣⾔型の設計 • マイクロサービスとその課題に対してのアプローチ • コンテナデザインパターン
• 拡張性を考えた実装 • 規格の標準化による拡⼤
54 個⼈の成⻑なくして会社の成⻑なし
55 どうすれば学べるか •(勉強)本を読む •(⾏動)触る •(実践)業務に⼊れてみる •(痛み)失敗して理解し成⻑する •(圧倒的成⻑)当たり前に使う環境に変える
56 ご静聴ありがとうございました