オンプレ脳の人ができるだけ勉強せずに「 k8s上でシステムを稼働まで持ってく(いきたい)」話

Kubernetes超入門勉強会オンプレ脳の人が勉強せずに「k8s上でシステムを稼働まで持っていきたい」話
Kubernetes超入門勉強会 #beginners_tech
オンプレ脳の人が
オンプレ脳の人が
勉強せずに
勉強せずに
「
「k8s
k8s上でシステムを
上でシステムを
稼働まで持ってく
稼働まで持ってく
(
(いきたい
いきたい)
)」話
」話
Ver 1.0
できるだけ

目次
1.最近、気づいたんです…
2.本日の注意書き
3.なぜk8sの仕事をやることになったか
4.「k8s」というものの自分の理解
5.「仕事でやる」て時に考えたこと
6.全体構成の設計
1.環境種の考慮
7.全体構成の構築
1.メンバーがメンテ出来るか
2.環境種毎の差異分離(コードを一つにできないか)
8.アプリ構成(k8s内)の構築
9.リリースプロセス設計
10.運用設計・トラブル時対応
11.ハマり点
12.大事なこと
13.まとめ

1.最近気づいたんです…
1.最近、
気づいたんです…

最近気づいたんです…
俺、「35歳定年説」
…を越えられなかった
のかもしれない…。

「勉強」「仕事」って
ラベルがつくと
「てんでダメ」古い知識を過信して
それで「なんとかしよう」
と最適性を考えない
ムキになる…
新しいことに挑まない、
勉強しない…

「勉強」「仕事」って
ラベルがつくと
「てんでダメ」古い知識を過信して
それで「なんとかしよう」
と最適性を考えない
ムキになる…
新しいことに挑まない、
勉強しない…
そうすると
どうなるか…
例えば、

クラウドのシステム設計
「多めにとっとけ」的
インスタンス
スペック高
＆常時起動
プロダクトの
種類や性質を知らず
「ぜーんぶ、仮想機で
自力構築」
事前設計ヘビーな
「時間掛かる上
決まるまでやらない」
古典的インフラ
脳
インスタンスは
「多重責務」
「状態持ちまくり」
全部手作業、
再現性皆無

クラウドのシステム設計
「多めにとっとけ」的
インスタンス
スペック高
＆常時起動
プロダクトの
種類や性質を知らず
「ぜーんぶ、仮想機で
自力構築」
事前設計ヘビーな
「時間掛かる上
決まるまでやらない」
古典的インフラ
脳
インスタンスは
「多重責務」
「状態持ちまくり」
全部手作業、
再現性皆無
「クラウド出来る！
経験あり！」
ってイキがってたけど、
やってんのは
「オンプレの構成を
クラウドで再現している」
だけ…なんじゃ？

いかんいかん…
ネガティブになったら
あかんし、現状を
変えなな…

でも、ちゃうねん…
「それしか出来ひん」
ねん…

でも…「新しいことを身
に着けたい」けど「勉強
したくない(というより出
来ない)」でも「新しいこ
とを身に着けたい」けど
「勉強したくない(という
より出来ない)」でも「新

エンタメですかね…
本日は
「35歳限界を迎えている
オンプレ脳の人が、
ほぼ無勉強(入ってからも
無勉強)でk8sに飛び込んだ
らどうなるのか？」
という「生態サンプル」を
観察していただきます。

エンタメですかね…
• お若いかつこれからやる方
–「反面教師」にして、地雷回避に役
立てたらいかだでしょうか
• 同年来の方で出来る方
–「笑いの種」にどうでしょうか
• 同じ状況の方
–「涙流しながら共感」してください

三浦一仁(みうらかずひと)
事故紹介？
• 通称:みうみう
• Twitter:@kazuhito_m
• Github:kazuhito-m
• フリーランス
– 最近はサービス作ってた
• 好きなもの:自動化,
「継続的ほにゃらら」
– CI/CDとか大好物

三浦一仁(みうらかずひと)
事故紹介？
• 通称:みうみう
• Twitter:@kazuhito_m
• Github:kazuhito-m
• フリーランス
– 最近はサービス作ってた
• 好きなもの:自動化,
「継続的ほにゃらら」
– CI/CDとか大好物
平凡な
「プログラマ」
です。

これから
「考え得る
最大限の
"予防線"」
張りまーす

想定問答
調べが足りない、
そんなアバウトな
知識で触るな
そんな
無責任な態度で
プロジェクトを
するな
その運用だと
絶対に
痛い目にあうぞ
そんなデマを
吹聴されると、
業界にとって
害悪
まわりに
迷惑をかけるな

想定問答
調べが足りない、
そんなアバウトな
知識で触るな
そんな
無責任な態度で
プロジェクトを
するな
その運用だと
絶対に
痛い目にあうぞ
そんなデマを
吹聴されると、
業界にとって
害悪
まわりに
迷惑をかけるな
全部
「そら言われるやろ」
と思っての発表です
ので、
勘弁してつかーさい
※ただし「デマを吹聴されると業界にとって害悪」
だけは教えて

• 胡散臭いです
– 題名からして「k8sを勉強してない」ので
– 「裏とってない」ため他所で言うに責任持てません
• 普通は「こんなんやったらだめ」です
– k8sの使い方的にも、お金の使い方にも、社会人倫
理的にも、グレタさん(世界の環境資源)的にも
• 内容が「アレ」なんで、資料公開は…どうで
しょう？
• 作ってみてからわかったんですけど
「あんまk8sの話してない」かもしれません

3.なぜk8sの仕事をやる事になったか
3.なぜ
k8sの仕事
をやる事に
なったか

ジェット
コースター
「あらすじ」

とある会社の人々
ジェットコ−スター「あらすじ」
アプリ畑の
アーキテクト
インフラエンジニア
(みうらと元同僚)
ある勉強会の懇親会にて

アプリ畑の
アーキテクト
(みうらと元同僚)
クラウドは
仕事でやってる
GCPも
やってる
k8s
やったことある
AWSやけど…
言うて…
ComputeEngine,Functins,GKE(一瞬),
CloudSQL,StackDriverとFireBase
くらいの「限られたやつ」
を「仕事以外」で
ローカルで
クラスタ立てて
自身のアプリを
立ち上げた程度
やけど…
正直な(嘘は言うてない)自己紹介

アプリ畑の
アーキテクト
これから「受託開発」
かつ「クラウドでやってく」
ための「ベースパターン」
作りがしたい
k8s/GKEなら
「アプリ構成は
k8sのマニュフェスト
変えたら対応できる」
ので、それ以外は
使い回せる、
という目論見
実際
「そううまく行くか？」
は「一例目(一案件目)」を
運用可能にしてから判断
この会社(の中の人)の目論見

アプリ畑の
アーキテクト
K8s
やりたい
なんか
「猫も杓子もそういうてる」
から
なんで？
「やってます」言うたら
かっこよくね？
「楽したかった」から
なぜ「楽」
できる？
「息が長そう」で、
「個別の組立てせんでいい」
っていう
「鉄板テクニック」
を身に着けたい

アプリ畑の
アーキテクト
K8s
やりたい
なんか
「猫も杓子もそういうてる」
から
なんで？
「やってます」言うたら
かっこよくね？
「楽したかった」から
なぜ「楽」
できる？
「息が長そう」で、
「個別の組立てせんでいい」
っていう
「鉄板テクニック」
を身に着けたい
利害
一致

アプリ畑の
アーキテクト
突然の「焼肉屋呼出し」
突然の「契約とかの話」
えーっと、「日程」と
「条件」なんですが…
プロジェクトマネージャー

アプリ畑の
アーキテクト
突然の「焼肉屋呼出し」
突然の「契約とかの話」
えーっと、「日程」と
「条件」なんですが…
プロジェクトマネージャー
みうら、
案件参画

仕事に入るときの自身状態、条件、実態
入った時点で「決まってた」こと
• アプリが.NET Core
• 大まかな「システム一式の
構成」
• 開発プロセスがWF風
• 画面設計
• インフラはGCPでやる
• 次年4月に運用開始
入った時点で「決まって無かった」こと
• インフラの設計
インフラチーム(みうら含む)への要求
• 動くこと
• 運用出来ること
みうらへの要求
• CI/CDの整備
• インフラチームへのアドバ
イス
• 週一日の稼働＆出社

だったのだが
現地に行って
解ったことは…

インフラチーム
• 「インフラの」という主語で始まるものの
– 構築・テスト等の「ロードマップ」が無い
– どう作ってくかの「プラン」が無い
– 「プロセス整備」や「成果物の定義」が無い
• チーム構成が
– アプリ:アーキ1人、デベロッパー5,6人
– インフラ:インフラエンジニア(リーダー)と俺の2人
アプリチーム
アーキテクトインフラエンジニア
(リーダー)
デベロッパー

インフラチーム
• 「インフラの」という主語で始まるものの
– 構築・テスト等の「ロードマップ」が無い
– どう作ってくかの「プラン」が無い
– 「プロセス整備」や「成果物の定義」が無い
• チーム構成が
– アプリ:アーキ1人、デベロッパー5,6人
– インフラ:インフラエンジニア(リーダー)と俺の2人
アプリチーム
アーキテクトインフラエンジニア
(リーダー)
デベロッパー
なので…

• みうらの責務の変更
– インフラチームの一員として働く
• 実際の設計構築を行う人員として
– とはいえ「リーダーと俺(週一のメンバー）のみ」
だが
• 入ってから「はっきりとさせた」こと
– k8sを使う
– (k8sは)GKEを使う
– アプリの構成
– SLA("停止”というものの運用設計)

と、
ここまでが
2019年4月
までのあらすじ

.NETCoreが動くなんか土台
開発対象となるシステム
SPA
本体用WebAPI
C#製DLL
WebAPI
C#製DLL
案件/勤怠/請求/給与管理社内システム(リプレース)
RDBMS
Postgres
ブラウザでアクセス
ツール等でアクセス
WebApp
EUC-API
社内は「人数限られてる」
でも「他拠点運用」など、
「徐々に利用者増」が
確定している(らしい)
たぶん「社内イベント等
重たい機能に負荷集中」
とかはあるだろうが、
Publicサービスのように
「跳ねる」事はないだろう

開発対象となるシステム
SPA
本体用WebAPI
C#製DLL
WebAPI
C#製DLL
案件/勤怠/請求/給与管理社内システム(リプレース)
RDBMS
Postgres
ブラウザでアクセス
ツール等でアクセス
WebApp
EUC-API
…程度の
決まって無さ
からのスタートです。

4.「k8s」というものの自分の理解
4.「k8s」
というものの
自分の理解

一般的に知られていること
• KubernetesはGoogleエンジニアが作った「コン
テナオーケストレーション・プラットフォーム」
– サーバ運用経験、前身「Borg」から続く「ベストプラ
クティスの結晶物」
課題になりやすい「システム構成」や
「運用」のベストプラクティスな機能
• ローリングアップデート
• オートスケーリング
• 死活監視
• 障害時セルフヒーリング
• サービスディスカバリ
• ロードバランシング
コンテナを元にした
「抽象化したパーツ(object)」を組み合わせ
システム構成をyamlで定義
Ingress
Service
Pod
Deployment
Volume

オレの「脳内」のk8s
• k8s自身も「コンテナ(Pod)」で作られてる
– ”kubectl get pods --namespace kube-system” を
叩いて眺めてみる
• 「コンテナ・コンテナ管理」の抽象化のため、「Pod」
など、ランタイムに寄らないような再度の概念定義をし
ている
– と言いつつも先駆けと成ったDockerの概念多し
• アプリとアプリ構成のAsCode養成ギプス
– Docker自体も同じ
– yaml書いて”kubectl apply”叩きゃいい、という世界観
• サービス小分け&最小化＆イミュータブル化の養成ギプ
ス

人類のk8sとの関わり方
Kubernetes
本体
運用
k8s運用者
システム
デプロイ
・運用
システム設計・運用者
システム
利用
システム利用者(エンドユーザ)

人類のk8sとの関わり方
Kubernetes
本体
運用
k8s運用者
システム
デプロイ
・運用
システム設計・運用者
システム
利用
システム利用者(エンドユーザ)
ここが
辛い！
誰かに
なすりつけ
たい…
なのでっ
「クラウド・マネージド
なKubernetes」
を使いたい！
てことで、今回は
「Google Container
Engine (GKE)」

• 高可用
– 無停止
– サービスダウン
しにくいシステム
• リソースの高集積
– よくある「自社の
休耕機を束ねて」
とかの用途に
合っている
• アプリの「構成」と
「運用」の均一化
– 自社に大量のアプリ
が在る場合など
• 運用のGoodParts
の模倣
– Googleのノウハウを
いただき♪
– 自動化で楽ちん♪
一般的なユースケース

• 高可用
– 無停止
– サービスダウン
しにくいシステム
• リソースの高集積
– よくある「自社の
休耕機を束ねて」
とかの用途に
合っている
• アプリの「構成」と
「運用」の均一化
– 自社に大量のアプリ
が在る場合など
• 運用のGoodParts
の模倣
– Googleのノウハウを
いただき♪
– 自動化で楽ちん♪
一般的なユースケース
今回「何一つ
合致してない」
きっちり「メンテ停止時間取る」し…
「扱うシステムたった一つ」やし…

でも、
やる
前述の”目論見”参照

入った時点のk8s(と周辺)知識
※今覚えば＆本人の感覚調べ
当時
• Dockerはある程度
• k8sは「前述」の理解程度
• GKEクラスタ立て&アプリ上げれる程度
– そのマニフェスト作成と反映コマン
ド叩ける程度
• Cloud Native Traile Mapなんて全然
登ってねえ…
※現在色々知って＆本人の感覚調べ
本当に必要だったもの
• GKE/GCP/k8s/Docker で「モノ作
る」仕事だよ(そりゃそうだ)
• プログラム言語の一般知識より、「この
プロジェクトのコード」を読んでること
のほうが重要
– トラブルシュート時に、必ずと言っ
ていいほど「そのPJ固有の深い問
題」に当たる

入った時点のk8s(と周辺)知識
※今覚えば＆本人の感覚調べ
当時
• Dockerはある程度
• k8sは「前述」の理解程度
• GKEクラスタ立て&アプリ上げれる程度
– そのマニフェスト作成と反映コマン
ド叩ける程度
• Cloud Native Traile Mapなんて全然
登ってねえ…
※現在色々知って＆本人の感覚調べ
本当に必要だったもの
• GKE/GCP/k8s/Docker で「モノ作
る」仕事だよ(そりゃそうだ)
• プログラム言語の一般知識より、「この
プロジェクトのコード」を読んでること
のほうが重要
– トラブルシュート時に、必ずと言っ
ていいほど「そのPJ固有の深い問
題」に当たる
エグい
スキルアンマッチ
だが…
いったい
どうなって
しまうのか！？

5.「仕事でやる」
て時に
考えたこと

• 前提条件(のおさらい)
– 自分は「週一」の稼働である
– 戦略もロードマップもスケジュールもない
– 同チームのになるインフラTリーダーは
「日々、トイルに追われている」
• めっちゃ「最低ラインの状態」を定義
– オレ一人で一年間(4 * 12 = 48日間)で出来る事
– 最悪「一人を人身御供に差し出せば、アプリが動
く」という状態まで持ってく
• 手動バリバリ＆張り付きっぱなしでも動いとるからヨシ
• 健全かどうかはわからんが…

人的リソースの無さ
に抗うため…
「指針」を
置こう！

• 再現性
–AsCodeか、出来なければ「手順書」最悪「メ
モ」で「頑張れば同じ様に出来る」証跡の残し
–その「履歴管理」も
• 自動化
–「人間の行動」や「開発のプロセス」を、極力
邪魔しない仕組みづくり
• デベロッパが「ふつーに開発してれば」デプロイ出来る
–ただし「すべてのものは頑張れば手動でも出来
る」ように
自分(とチームが)目指す「指針」

6.全体構成
の設計

全然わからん…せや！
一度「オンプレ脳」で設計してみよう！
って感じでやってようかな？
1.オンプレでやる場合の設計
2.コンテナ化した(だけ)場合の設計
3.GCP/GKEでやる場合の設計

6.1.環境種の考慮
6.1.環境種
の考慮

• 今回、「環境種」というのを「何種類、
どんだけ設けるか」をまず決めないと…
Production
Staging
「本番」。商用環境、お客さんが実際に使う。
Productionとほぼニアリー、最終確認場。
• ここらへんは「一般化されてるもの」だと思う
• ※下位の環境種でテストしたものしか、
上位の環境種に反映してはならない

Production
Staging
Develop
• 呼び方は適当(本プロジェクトではコレ)
• 最新の本線ソース(masterなんだか
developなんだかfeatureなんだか、そ
んなん)をデプロイしている場所
• 「CD(ConteniusDerivary/Deproy)の
実績積み・修練場」としての役割が大き
い
は、プロジェクトごとに個別に設計するもの

Production
Staging
Develop
用途A 用途B 用途C
• 用途別環境
• 「〜の検証用」「〜データ固定」など、
用途で暫く固定される
• デプロイのタイミングも「用途で任意」
は、もうプロジェクトごと…
と言うより、状況ごとに発生する

Production
Staging
Develop
用途A 用途B 用途C
• 用途別環境
• 「〜の検証用」「〜データ固定」など、
用途で暫く固定される
• デプロイのタイミングも「用途で任意」
は、もうプロジェクトごと…
と言うより、状況ごとに発生する
みたいな
「環境種」
をどう
実現しようか

• 今回使う「器(うつわ)」の包含関係
GCP
Project(GCP内の単位)
GKE
クラスタ(Node群)
Name Space(使うかは任意)
システム構成(三浦の考える論理的概念)
Podなどの(k8s内)構成部品

GCP:Project:GKE…が一つ
クラスタ_1 クラスタ_2
PrdNS StgNS
DevNS
用途別NS
GCP
Project_1 Project_2
クラスタ
PrdNS
クラスタ
GCP
Project_1
Project_2
Prdクラスタ
GCP
Project_1 Project_2
クラスタ
PrdNS
クラスタ
StgNS
DevNS
用途別NS
Stgクラスタ
Devクラスタ
用途別クラスタ
案1 案2
案3
• k8sはクラスタに「まとめて入
れた」ほうがお得(多分料金)
• 本番だけは他環境の影響食らう
わけには行かない
ので、案1〜3を提案したが…

インフラチームのリーダ曰く…
• 料金がわかりにくそう
• 「環境種」との対応がわかりにくそう
な「ダイナミック☆根本から分割」方式に
(が今はデメの方が多いって後悔してるみたい)
GCP
Production用Project
Staging用Project
Develop用Project
用途別用Project

対象と成るシステム
SPA
本体用WebAPI
C#製DLL
WebAPI
C#製DLL
RDBMS
Postgres
WebApp
EUC-API
コレが元なので…

閉域網
1.オンプレでやる場合の設計なら…
Postgres入りLinux
RDBMS
こんな感じかな？
.NETCore入りLinux
WebAPP
.NETCore入りLinux
WebAPP
.NETCore入りLinux
EUC-API
.NETCore入りLinux
EUC-API
Load
Balancer
Nginx/Linux等
で自前か
専用機器にするか…
Load
Balancer
DNS
Server
ネットワーク
分けるか…
HA化を
検討するか…
監視系
サーバ
Port:443
Port:443
アプリの
任意Port
証明書
証明書

閉域網
Docker入れたLinux
2.コンテナ化(だけ)場合の設計なら…
Postgres入り
Conatiner
RDBMS
こんな感じかな？
.NETCore Container
WebAPP
.NETCore Container
WebAPP
.NETCore Container
EUC-API
.NETCore Container
EUC-API
Nginx LB
Container
DNS
Server
監視系
サーバ
Port:443
※要求URLで割り振り
こうしちゃうと
「ただサーバ一台になった」
だけで可用性下がるので
実際はもっと
分割設計が必要
docker-compose
で、実際に
試作しました
証明書

GCP
VPCネットワーク
Deployment
3.GCP/GKEでやる場合の設計なら…
Cloud SQL
(Postgres)
RDBMS
コレでどうだ！
.NETCore入りPod
WebAPP
.NETCore入りPod
WebAPP
Deployment
.NETCore入りPod
EUC-API
.NETCore入りPod
EUC-API
Ingress
Cloud
DNS
StackDriver
(Logging
/Monitoring)
Port:443
GKE(k8s)
Service
Service
外部IPアドレス
(固定予約IP)
Managed
Certificate

GCP
Deployment
3.GCP/GKEでやる場合の設計なら…
Cloud SQL
(Postgres)
RDBMS
コレでどうだ！
.NETCore入りPod
WebAPP
.NETCore入りPod
WebAPP
Deployment
.NETCore入りPod
EUC-API
.NETCore入りPod
EUC-API
Ingress
Cloud
DNS
StackDriver
(Logging
/Monitoring)
Port:443
GKE(k8s)
Service
Service
(固定予約IP)
Managed
Certificate
なんか…
行ける気が
してきた！

7.全体構成の構築
7.全体構成
の構築

7.全体構成の実際の構築
• アバウトな設計が終われば
「k8s内(マニフェスト)以外のガワ」
を作ることは出来るだろう
• ガワ、つまり
「GKE以外のGCPのプロダクト」
で必要なものは…

GCP
Deployment
Cloud SQL
(Postgres)
RDBMS
.NETCore入りPod
WebAPP
.NETCore入りPod
WebAPP
Deployment
.NETCore入りPod
EUC-API
.NETCore入りPod
EUC-API
Ingress
Cloud
DNS
StackDriver
(Logging
/Monitoring)
Port:443
GKE(k8s)
Service
Service
(固定予約IP)
Managed
Certificate
ココ
以外
の…

しかし、先程掲げたのは…
• 再現性
–AsCodeか、出来なければ「手順書」最悪「メ
モ」で「頑張れば同じ様に出来る」証跡の残し
–その「履歴管理」も
であるため、この「GCPのガワ」を作る作業も出
来ればAsCodeしたい
• 課題は2つ
1.メンバーがメンテ出来るか
2.環境種毎の差異分離(コード一つに出来ないか)

.1.メンバーがメンテ出来るか？
7.1.メンバー
がメンテ
出来るか

7.1.メンバーがメンテ出来るか？
• GCPの構成をAsCodeするには3択くらいあり
1.TerraForm
2.GCP Cloud Deployment Manager
3.bash等で”gcloud”コマンドを使ったスクリプト
●
俺はTerraFormを押したかったのだが…
「Terraformなんか知らない。”今から”なら
学習コストが…初物づくしでAsCodeにまで言
語学ぶなら、間に合わんしメンテできん」
●
ということから上記3.になりました
(現在、リリース後、2.に取り組む案あり)

7.2.環境種毎の差異分離
7.2.環境種毎の
差異分離
(コードを一つに
できないか)

• bashによるスクリプト化が決まった
• 問題は「環境種毎の差異」
• もうちょっと細かく言うと…
1.IDやスペック値など「環境毎に変わるもの(変数)」
2.特定環境にしか用意しない物(在ったり無かったり)
• 例えば…
– 2.は「DNSはProd用はProd-Project、それ以外
はStaging-Projectに置く」という特殊設計にした
ので、「CloudDNSはProdとStagingにしかなく
、かつ内容が違う」
• ココらへんを「どう管理するか」

結局
– 全環境統一スクリプトをアプリのリポジトリに置く
– 「環境毎の変数」「環境毎に在ったり無かったりす
るもの」は、bashのカタチで環境毎Projectのソー
スリポジトリに置く
にした
Production用Project
Staging用Project
Develop用Project
環境毎リポジトリ変数差異部分構成スクリプト
環境毎リポジトリ変数差異部分構成スクリプト
アプリのリポジトリ全環境統一構成スクリプト
実行時に
食わす
ちょっと煩雑
かな…？

8.アプリ構成
(k8s内)
の構築

GCP
Cloud SQL
(Postgres)
RDBMS
Cloud
DNS
StackDriver
(Logging
/Monitoring)
Port:443
(固定予約IP)
先程の「全体設計」の構成からk8s部分だけ
を、マニフェスト(というyaml)に書き起こす
こ
こ
以
外
Deployment
.NETCore入りPod
WebAPP
.NETCore入りPod
WebAPP
Deployment
.NETCore入りPod
EUC-API
.NETCore入りPod
EUC-API
Ingress
GKE(k8s)
Service
Service
Managed
Certificate

• できました : https://is.gd/VtAiBN
• マニフェストを「環境種に左右されず、統一」
したい
– GCP自体と同じこちらも(というよりこちらこそ)
• 「コンテナに渡す環境変数」は「書き換える」
仕組みがある
– 「envFrom:configMapRef」
– 予め「kind: ConfigMap なyaml」を読み込ませ
ておけば、マニフェストから指定することにより
「コンテナの環境変数として読み込める」もの

• できました : https://is.gd/VtAiBN
• 問題は「コンテナの環境変数以外」で、
「環境ごと(なんあらデプロイ毎)に変わる値」
– 「世のテンプレートエンジンぽいもの」を検討した
が、どれも「仰々しい(管理厳しい)」ように思えた
• 置き換えたいのは2種類/5箇所だけ
1.コンテナイメージのバージョン
2.エンドポイントのURL
• 「ConfigMapに書いた」上で、「自力でマニ
フェストのテンプレートファイルから生成す
る」スクリプトを作成、デプロイ時に叩く様に

9.リリースプロセス設計
9.リリース
プロセス設計

資料
間に合わず
割愛！

10.運用設計・
トラブル時対応

• 「運用テスト」で掬い上げ中
– 「動いてる」を正常な状態として、実際「顧客の運
用テスト(業務面)」にて出てきた
• トラブル・困りごと
• かつ「アプリ以外の事」
がでれば、その対処と自動化を検討
• ただし「負荷テスト」は別途
– 上記は「顧客視点での運用回るか」のテストなので
• 別の工夫として「GKE/k8sに”自分たちで使う
ツール”をデプロイ・運用」している
– GROWIというWikiを運用している
– マニフェスト書きのトレーニングと「運用の知見」
を貯めるため

11.ハマり点
11.ハマり点

10.ハマり点
• メモリリークや「無限にメモリに貯める処理」
は、いくらk8sさんでも死ぬ(サービスダウン)
– (設定によると思うけれどデフォルトで)k8s/GKEは
• 負荷に応じて拡張(スケールアウト)する
• 応答不能になったらPodを殺しに行く(status:Evicted)
という挙動をする
• 「1リクエストに数百Mメモリを使い、ある程
度停滞するページorAPI」作ってしまった場合
– 次々に拡張していった後、サービスダウンする
• お金を頬張りながら死への行軍
– お金と引き換えにダウン頻発も嫌だし、精緻な見積
もりして制約かける…とかはクラウドの恩恵減る

10.ハマり点
GKE・クラスタ内
Pod Pod
Node(1) Node(2)
• GKE(k8s)はクラスタの中にNode(実体はGCE) を複数台
持ちます
• 負荷の少ない状態(”凪”の状態)からスタートです
• ※説明のため、若干ディフォルメをしています
利用メモリバー
(下向き、
増えると下へ)
Podの中身(仕事) は
「Webアプリ」
と想定

10.ハマり点
Pod Pod
Node(1) Node(2)
• 「1リクエストに数百Mメモリを使い、ある程度停滞する
ページorAPI」があり、殺到して呼び出されたとします
• 「ある程度停滞」は、k8sが「負荷が高い」と捉え、Pod
をスケールしていきます
Pod Pod

10.ハマり点
Pod Pod
Node(1) Node(2)
• 応答不能の時間が長いorPodのメモリ上限を使い切ってい
る、と判定すると、k8sはPodを殺しに行きます
(本来であれば、正常復帰に向かうための行為です)
Pod Pod
Pod Pod

10.ハマり点
Pod Pod
Node(1) Node(2)
• Nodeのメモリ上限に近づいた状態でPodがスケールされると
– Node自体のメモリ上限に差し掛かるとPodが殺されます
– Podの「最低起動可能メモリ」が確保出来なければ、そもそ
もスケール出来ません(死亡ステータスの残骸が出来る)
Pod Pod
Pod Pod
Pod Pod

10.ハマり点
Pod Pod
Node(1) Node(2)
• GKEには「Node自体のオートスケール機能」が在ります
(クラスタオートスケーラー)クラスタ作成時に指定出来ます
• Podの要求により「クラスタがPodを生成できなそう」ならス
ケールされます
Pod Pod
Pod Pod
Node(3)
Pod

10.ハマり点
Pod Pod
Node(1) Node(2)
• 殺到状態が続くと、新たなノードもすぐ枯渇するでしょう
• Nodeのスケール数にも限界数があるので、スケールできなく
なります
– 無限にされても「お金が枯渇する」しね…
Pod Pod
Pod Pod
Node(3)
Pod
Pod
Pod
Pod Pod Pod

10.ハマり点
Pod Pod
Node(1) Node(2)
• すべてが枯渇した状況で「中で目まぐるしく誕生と殺戮が行わ
れている」かもしれません
• がユーザからみれば「リクエストを延々と待ってる」「待たさ
れたがエラー」「そもリクエストが送れない」です
• すなわち「サービスダウン」です
Pod Pod
Pod Pod
Node(3)
Pod
Pod
Pod
Pod Pod Pod

10.ハマり点
• つまりは…
– アプリを”コンテナ時代”に合わせた”軽いモノ”とし
て設計しましょう
– バグは出さないようにしましょう
• これ…端的に言えば「
Cloud Native Trail Map のStep.1にすら
到達していない」ということかもしれない…

10.ハマり点
• つまりは…
– アプリを”コンテナ時代”に合わせた”軽いモノ”とし
て設計しましょう
– バグは出さないようにしましょう
• これ…端的に言えば「
Cloud Native Trail Map のStep.1にすら
到達していない」ということかもしれない…
アプリの設計ミスや
バグは
k8s/GKE使っても
「治らない」し
「カバーできない」

10.ハマり点
• それ以外の「しんどかったわー」
– GKEではGUIからでもマニフェスト作れるけど「や
めたほうがいい
– GKEのIngressは曲者
– GCPのIAMは…なんてか独特で複雑(かも)
– IAMの権限のProject跨ぎは…出来るけど特殊
– 自分たちも「手探り」な分野…なのに新人研修？

12.大事なこと
12.大事な
こと

11.大事なこと
• 当たり前のこと…かもだけど
– 今回は「故意に健忘」してるけどな！
– 本来、自動化は「対象プロセスを整理」して「こな
れ」て、そこを「機械化」するもんだから
• 例えば、前述の「ハマり点」
– 当時「そう挙動していること」を理解してなかった
し、トラブってるし、わからんけど数時間後に回復
してるし…あとでトレースするまで解らん事ばかり
– 「防止策や対応」など「次の一手が打てなく」なる
「高度に自動化されているモノ」を
「手放し運転」できるのは、
「その中身を知ってる状態」が前提だ

12.まとめ
13.まとめ

12.まとめ
• 「目的」と「得られる利点の理解」と「今後ど
うしたいか」がないとk8sはオーバ−スペックか
も？
– 「技術負債」「お高い買い物(しかも継続)」可能性
– 「k8sで在る理由やベネフィット」を享受できなくて
も良い…ならやってもいいかもね
• 「オンプレ知識」「無勉強」でも「設計」に
よっては乗り越えられる…かも？
– かどうかは未だ結果が出てない
– 2020年4月以降の「後編」にこうご期待！

X.参考サイト
• k8s自体
– https://www.redhat.com/ja/topics/containers/what-is-kubernetes
– https://ja.wikipedia.org/wiki/Kubernetes
• Docker以外のRuntimeの可能性
– https://www.publickey1.jp/blog/20/dockerkubernetes.html
• k8sのメモリ枯渇について
– http://dr-asa.hatenablog.com/entry/2018/04/10/171807
– https://kubernetes.io/ja/docs/tasks/configure-pod-container/assign-memory-resource/
• GKEのクラスタオートスケーラー
– https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-autoscaler?hl=ja

オンプレ脳の人ができるだけ勉強せずに「 k8s上でシステムを稼働まで持ってく(いきたい)」話

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to オンプレ脳の人ができるだけ勉強せずに「 k8s上でシステムを稼働まで持ってく(いきたい)」話

Similar to オンプレ脳の人ができるだけ勉強せずに「 k8s上でシステムを稼働まで持ってく(いきたい)」話 (20)

More from Kazuhito Miura

More from Kazuhito Miura (20)

Recently uploaded

Recently uploaded (9)

オンプレ脳の人ができるだけ勉強せずに「 k8s上でシステムを稼働まで持ってく(いきたい)」話