この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
みなさん、こんにちは！
AWS事業本部の青柳＠福岡オフィスです。
先日、福岡で Kubernetes を語るコミュニティ「
#ふくばねてす」の第2回ミートアップ、その名も「#ふくばねてす node-2」が開催されました。
第1回は残念ながら参加できなかったのですが、今回念願叶って参加してきましたのでレポートしたいと思います。
「ふくばねてす」とは
福岡でKubernetesをやっていくコミュニティ、「FuKubernetes」という名前だけ思いついた。あとはどなたかミートアップ開催してほしい
— Uchio KONDO
ということで、ダジャレから始まった「伝説の最ユル Kubernetes コミュニティ」だそうですが・・・
いやいやしかし、「最ユル」と言いつつ第1回ミートアップはなかなかの「濃さ」だったという噂も聞きました。
はたして真相はどうなのでしょうか？？
会場の様子
ミートアップは、福岡市が官民共同でスタートアップを支援する施設「Fukuoka Growth Next (fgn.)」のイベントスペースで行われました。
昭和4年に建築された旧・福岡市立大名小学校の校舎を改装してできた施設ですが、最近リニューアルが行われ、以前より一層「オサレ」な感じになっていました。
セッションレポート
Session 1「コンテナ移行におけるアレコレと使えるアレコレ(仮)」
- 発表者： Transnano さん
- ヤフー株式会社 所属
- バックエンドエンジニア (SRE)
Envoy について
「アレコレと使えるアレコレ」とは何のことだろう？ と思いましたが、Kubernetes でサービスプロキシとして用いられる「Envoy」についてのお話でした。
- Envoy とは何か？
- C++ で書かれた高性能な L3/L4/L7 プロキシ
- Lyft が開発し、現在は Cloud Native Computing Foundation (CNCF) の管理下
- CNCF において Kubernetes、Prometheus に続く 3 番目の「Guraduated Project」(＝実用段階に到達)
「サイドカー」について
Envoy の利用形態には「スタンドアロン」「サイドカー」があり、今回は特に「サイドカー」についての説明がメインでした。
- スタンドアロン
- 複数のアプリケーションに対して1つの Envoy、アプリケーションの前段に配置する
- 主に物理サーバーや仮想サーバー
- サイドカー
- アプリケーションと1対1、アプリケーションに「横付け」するように配置する
- コンテナ (特にコンテナオーケストレーション／マイクロサービス)
- サイドカーの特徴・利点
- アプリケーションの入出力を Envoy 経由にすることで、Envoy に処理を行わせる
- アプリケーション本体に変更を加えることなく、機能を追加できる
Envoy で実現できること
Envoy にはさまざまな機能があるとのことですが、今回は「Resilience (弾力性)」「Observability (可観測性)」に絞って解説されました。
Resilience (弾力性)
- Circuit Breaking
- アプリコンテナでエラーや遅延が連続発生した際に、強制的に障害点を切り離す
- 障害の連鎖・拡大を防ぐ
- Automatic Retries
- アプリコンテナの呼び出しに自動リトライを付加する
- Envoy 側に機能を持たせることで、個々のアプリでリトライ処理を実装せずにすむ
- Rate Limits
- アクセス流量に制限をかけることで、スパイクに対応する
Observability (可観測性)
- Logs
- 既存サービスを改修することなく、ロギングを追加することができる
- Traces
- 透過的なトレースにより、サービスの処理時間などを分析できる
- Metrics
- 外部 ⇔ Envoy 間、Envoy ⇔ アプリ間の流量の統計を取り、Prometheus 等で可視化
まとめ
- Envoy はマイクロサービスに必要な機能を備えたプロキシ
- サイドカーとして使うことで、サービス本体の改造なしに機能追加が可能
Session 2「わりとゴツいKubernetesハンズオンそのあとに」
- 発表者： Kta-M さん
- 福岡のシステム開発会社 株式会社Fusic(フュージック) 所属
- IoT 開発支援サービス「mockmock」の開発担当 (プロダクトオーナー)
- 「Kubernetesは完全に理解している」 *1
「わりとゴツいKubernetesハンズオン」
社内で Kubernetes の入門向けに開催したハンズオンの内容を Qiita に公開したところ、かなりの評判になった (いわゆる「バズった」) とのこと。私のまわりでも話題になりました。
次なるハンズオン：「Kubernetes の CI/CD 環境構築」
- 最初のハンズオンでは・・・
- Kubernetes クラスタ環境を作るところまでがメイン
- アプリのデプロイ・動作テストはサンプル Docker イメージを利用
- 次なるハンズオンを企画
- オリジナルのアプリを構築
- アプリをビルド、デプロイする CI/CD 環境を構築
- Skaffold を使った CI/CD のハンズオン
- Skaffoldとは： Google 謹製の Kubernetes 開発支援ツール
まず、ローカルで Skaffold を使ってみる
- 準備
- Docker for Desktop の Kubernetes 機能を利用
- サンプルアプリケーション： GitHub の kubernetes/examples にある guestbook を使う
- Skaffold のインストール： Mac であれば brew でインストール可能
- Skaffold を使ったデプロイ
skaffold run： コンテナイメージのビルド～デプロイskaffold dev： ソースコードの変更を自動検知して、ビルド・デプロイを実行
- Skaffold でテスト
container-structure-test： コンテナイメージの構造をテスト
クラウド環境で Skaffold を使う
- 準備
- DockerHub リポジトリ作成
- EKS クラスタ作成
- Skaffold の設定ファイルをローカル向けからクラウド向けに修正
- CircleCI の設定： GitHub リポジトリを登録、AWS 認証情報を設定
- 実行
- GitHub にプッシュ → EKS クラスタ上にサービスがデプロイされる
まとめ
- 「わりとゴツいハンズオン」から一歩進んで、Kubernetes を使った開発のイメージを掴む
- Kubernetes 沼に足を踏み入れたばかり
- 俺たちの真の戦いはこれからだ！
Session 3「kubernetesのアップデートに関するあれこれ(仮)」
- 発表者： kyswtnb さん
- 株式会社ヌーラボ(Nulab) 所属
- Cacoo の開発を担当、SRE
Cacoo における Kubernetes アップデート
AWS Summit Osaka 2019 の基調講演 でも紹介されましたが、Cacoo は AWS 上で Kubernetes を採用してマイクロサービス化されています。
Cacoo で採用されているのは、いわゆる「Kubernetes on AWS」で、これはマネージドサービスである EKS を利用するのではなく、kops というツールを使用して AWS の VPC や EC2 などの環境上に Kubernetes クラスタを構築する手法とのことです。
1. kops？
- Kubernetes クラスタをコマンドラインでコントロールできる
- AWS を公式にサポート
2. node の kernel update
- kernel アップデートの必要性
- 「CPU 投機的実行に関する脆弱性」(Meltdown, Spectre) などへの対応
- アップデート実施
- パッチ適用済み kernel をベースにした EC2 AMI がリリースされているか確認
- ノード構築は Terraform を使用しているため、アップデートは比較的簡単
3. Kubernetes upgrade
- 開発環境をまずアップデート： 1.10.12 → 1.11.9
- 動かなくなった
- CHANGELOG をよく読む
- 原因： オプション
--enable-custom-metricsが削除されていた
4. Ingress nginx controller upgrade
- 開発環境をアップデート
- こけた
- CHANGELOG を確認： 「破壊的変更」(Breaking Changes) があった！
X-Forwarded-For:ヘッダの振る舞いが変更 → conf 記述の変更が必要
まとめ
- kops らくちん
- CHANGELOG よく読もう
Session 4「IstioによるTraffic Management」
- 発表者： loftkun さん
- ヤフー株式会社 所属
My k8s Environment
Kubernetes は前職で使っていたものの現職では使っていないそうで、自宅に Kubernetes 環境を構築したとのこと。その環境が・・・
- PC パーツショップの BTO マシンがベース
- CPU： Core-i7
- メモリ： 64GB (！！)
- Minikube、Istio、Helm をインストール
Minikube の起動オプション (Tips) も紹介していただきました。
minikube start vm-driver=virtualbox： 仮想マシン上で Minikube を起動- 現在はシングルノードのみ対応とのことですが、将来マルチノード化も予定されているとのこと
minikube start vm-driver=none： 物理マシン (ベアメタル) 上でMinikube を直接起動
Istio
- Istio とは
- サービスメッシュを構成する OSS
- 既存の分散アプリケーション上に、透過的に重なるサービスメッシュを提供
- 透過的に重なる： Envoy をサイドカーとして Pod へインジェクション (注入)
- サービスメッシュとは
- ディスカバリ、ロードバランシング、リカバリー、メトリクス、モニタリングなどを提供
- A/B テストやカナリアテストなど、複雑な運用要件に対応できる
- なぜ Istio を使うのか
- コード変更なしで、ロードバランシング、サービス間認証、監視などの機能を付与できる
- アーキテクチャ
- データプレーン (ワーカーノード) で動作： Proxy
- コントロールプレーンで動作： Mixer、Pilot
- Proxy から Pilot へは動作状況の収集、Pilot から Proxy へは設定・管理が Mixer を介して行われる
Istio の利用
- Istio のインストール
- Helm を使わない場合： istio.io から istio-demo.yaml をダウンロードして適用
- Helm を使う場合： istio.io の Doc に記載されている最新版をダウンロードして使用
※ Helm Charts の incubator/istio は更新が停止しているので使わない方がよいらしい
- サイドカーのインジェクション方法は2通り
- Automatic： namespace にラベルを付与することで自動的にインジェクションされる
- Mannual：
istio kube-injectコマンドを実行して手動で組み込む - いずれの方法でも、Pod の yaml ファイルに istio-proxy コンテナの記述が追加される
サンプルアプリを使った Istio の機能紹介
- Bookinfo サンプルアプリ
- フロントエンドアプリ (Python)： 書籍情報 Web サイト
- バックエンドアプリ (Java)： レビュー機能を提供するサービス
- フロントエンドにサイドカーをインジェクションすることにより、バックエンドアプリを切り替える
- サイドカーに設定する「ルーティングルール」の例
- 完全固定： 全てのリクエストを v1 アプリに向ける
- HTTPヘッダによる振り分け： (例) 特定ユーザーでログインしている場合のみ v2 アプリを提供
- Traffic Shifting： (例) 全体のトラフィックを 50:50 で v1 と v2 に振り分け
- カナリアリリースなどに使える
- Fault Injection
- サービス応答に故意に遅延を加えることで障害を誘発
- 障害を想定したテスト、カオスエンジニアリングに使える
Session 5「CNDT2019 見所をご紹介...???」
- 発表者： udzura さん
- GMOペパボ株式会社 所属
CNDT2019/OSDT2019
昨年まで「Japan Container Days (JKD)」として開催されていたイベントが、今年から名前を変えて「CloudNative Days」として4月の福岡を皮切りに各地で開催されます。
今月 7月22日～23日 には東京で CloudNative Days Tokyo 2019 / OpenStack Days Tokyo 2019 が開催されます。
間近に迫った CNDT2019/OSDT2019 の見所を、公式サイトで公開されているタイムテーブルを画面に映しながら「ずらずら～」っと紹介して下さいました。
たくさん紹介していただいたのでメモが追い付かず・・・
udzura さんが GitHub でも公開しているとのことですので、そちらを参照してみてください(^^;
まとめ
udzuraさん：「8トラックもあるので見たいのが重なってツラい、replicas: 8 したい」
ということで、Kubernetes を知っていれば「クスっ」となるまとめでした。
Session 6「反脆弱なシステムは目指してもいいものか？」
- 発表者： nwiizo さん
- GMOインターネット株式会社 所属
- レンタルサーバーサービス「ConoHa」の開発
- エバンジェリストとしてセキュリティミニキャンプの講師などもされている
「反脆弱性」とは
- 「脆弱」の対義語 ＝「堅牢」・・・ではない？
-
トライアド (三要素)
- 脆弱
- 堅牢
- 反脆弱
「脆弱」「堅牢 (頑健性・復元力)」「反脆弱」
- 脆弱 (フラジャイル)
- 一回の大きな変化で大きな損を出すもの
- 障害や変化などの影響が大きい
- 頑健性 (ロバスト)
- 大きな変化を受けても大きな損を出さないもの
- 障害や変化などの影響が小さい
- 復元力 (レジリエンス)
- ロバストをさらに発展させた考え
- 変化に強く、回復力が高い (障害や変化などが発生しても自動で回復する)
- 反脆弱 (アンチフラジャイル)
- 変化に対して損ではなく利益を生み出す
「反脆弱なシステム」とは
- 脆弱なシステム
- モノリシック
- コンポーネントが死ぬと全体が死ぬ
- 一つの機能をスケールさせるためには全体のスケールが必要
- 新機能を追加する時には全体との調和が必要
- 頑健なシステム
- マイクロサービス
- Single purpose (単目的)
- Loose coupling (疎結合)
- High cohesion (高凝縮)
- 復元力のあるシステム
- Resilient (弾力性)
- Flexible Scale (柔軟なスケーリング)
- Simplicity (単純さ)
- 反脆弱性なシステム
- Evolution Architecture
「反脆弱なオペレーション」とは
- 脆弱なオペレーション
- 人力 (手動オペレーション)
- シンプルで手っ取り早いが、再現性なし
- 頑健なオペレーション
- Infrastructure as Code
- 冪等性があるが、回復性もなければスケーリングもしない
- 反脆弱なオペレーション
- Orchestrator
- 変化に強く、再現性、冪等性、スケーリングする
- 複雑で学習コストが高い
クラウドネイティブ
- 障害適応学習
- 障害発生、障害対応からシステムを学び、通常変更のオペレーションなどを行っていく
- しかし、肥大化した分散システムでは障害が複雑になり、学習が追い付かない
- カオスエンジニアリング
- 分散システムにおいてシステムが不安定な状態に耐えることを検証する
- Observability (可観測性) が重要
- 「反脆弱」なシステム
- 変化に対して損ではなく利益を生み出す
- システムは完璧ではないものであり、変化や障害は必ず起こるもの
- ユーザー影響を限りなく少なくする
(すみません、このあたりで私の理解が追い付かなくなって、メモも意味不明になりました・・・)
発表者の nwiizo さんも「反脆弱」について模索中ということですが、「堅牢」とは違う「反脆弱」という概念について興味が湧いたセッションでした。
感想
終わってみて、なるほど・・・、噂に違わず「濃い」ミートアップでした。
それでも、Envoy や Istio など、私もちょうど興味を持っているところは、知っている内容は「ふむふむ」と押さえつつ、新しい知識も取り入れることができて勉強になりました。
また、Skaffold などのツールを使った実例の紹介もあり、試してみようと思いました。
今後も、福岡で Kubernetes が盛り上がることを期待です。
脚注
- 「理解度は『完全に理解した』→『なんも分からん』→『チョットワカル』の順に推移する」という有名なネタフレーズです。念のため。 ↩
35
