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
700
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
58
AWS Control Tower導入してハッピーになりました
shogomuranushi
0
89
EKS を使ってる人から見た App Runner
shogomuranushi
7
2.1k
Suggested Topicの質問に可能な限り答えてみた
shogomuranushi
0
960
顧客のアプリケーションコードが動くマルチテナント環境における課題とEKSにたどり着くまで
shogomuranushi
0
1.3k
ちょいテク100本ノック。できるまで帰しません 。今から使えるちょいテク集
shogomuranushi
1
1.9k
after of Infrastructure-as-Code-is-very-tired
shogomuranushi
16
3.2k
what is Cloud Run?
shogomuranushi
2
89
登壇資料_JAWS-UG_初心者支部_20190417.pdf
shogomuranushi
0
520
Other Decks in Technology
See All in Technology
Optimizing your Swift code
kateinoigakukun
0
1.3k
それでもどうしてRecoilを使うのか / Harajuku.ts Meetup Recoil
okunokentaro
13
3.7k
plotlyで動くグラフを作る
kosshi
0
740
Periodic Multi-Agent Path Planning
hziwara
0
110
私見「UNIXの考え方」/20230124-kameda-unix-phylosophy
opelab
0
160
グローバルチームことはじめ / Bootstrapping a global team
tasshi
1
650
Raspberry Pi Camera 3 介紹
piepie_tw
PRO
0
130
マネーフォワードクラウドを支える事業者基盤
machisuke
0
520
- Rでオブジェクト指向プログラミング- クラス設計入門の入門
kotatyamtema
1
720
オンプレk8sとEKSの並行運用の実際
ch1aki
0
160
【NGK2023S】 ノードエディタ形式の画像処理ツール「Image-Processing-Node-Editor」
kazuhitotakahashi
0
240
PCI DSS に準拠したシステム開発
yutadayo
0
290
Featured
See All Featured
The Language of Interfaces
destraynor
149
21k
Atom: Resistance is Futile
akmur
256
24k
Imperfection Machines: The Place of Print at Facebook
scottboms
254
12k
Fashionably flexible responsive web design (full day workshop)
malarkey
396
63k
Unsuck your backbone
ammeep
659
56k
Statistics for Hackers
jakevdp
785
210k
Building a Modern Day E-commerce SEO Strategy
aleyda
6
4.5k
Build The Right Thing And Hit Your Dates
maggiecrowley
22
1.4k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
657
120k
How GitHub Uses GitHub to Build GitHub
holman
465
280k
The Art of Programming - Codeland 2020
erikaheidi
35
11k
Art, The Web, and Tiny UX
lynnandtonic
284
18k
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 ご静聴ありがとうございました