LoginSignup
30
24

More than 3 years have passed since last update.

@zaki-lknrin株式会社エーピーコミュニケーションズ

CNDT2019/OSDT2019行ってきたのでスライドリンクとメモ(見つけ次第更新)

Last updated at Posted at 2019-07-23

CloudNative Days Tokyo 2019 / OpenStack Days Tokyo 2019、行ってきました。
スライドと、簡易版レポートというよりメモ
https://cloudnativedays.jp/cndt2019/

タイムテーブル(簡易版)

スライドリンク(整理中)

見つけ次第更新します。
公式でまとまるとは思うけど…

Day1

Day2

Cloud Native Deep Dive (ホワイトボードディスカッション)

見てたわけではなく、帰り際に撮影したものです。

IMG_20190723_182525.jpg

IMG_20190723_182431.jpg

IMG_20190723_182443.jpg

IMG_20190723_182456.jpg

IMG_20190723_182504.jpg

IMG_20190723_182519.jpg

動画

CloudNative DaysのYouTubeチャンネルから。
https://www.youtube.com/channel/UCMBw1Z3fmhe-2l-iq2p4rNw/videos

登壇振り返りや参加レポートなど

振り返りイベント

以下、受講メモ (いわゆる蛇足)

■ day1

[K1] Keynote

image.png

Opening

動画: 【CNDT-OSDT2019】Opening Act by Akihiro Hasegawa - YouTube

「クラウドを使いましょう」→「クラウドからクラウドネイティブへ」
+Native

CNCF： Cloud Native Trail Map

アンケート(母数1354の時点):
来場者の+46%がすでに本番環境でクラウドネイティブ技術を活用している。

CNCF企業別commit数(直近180日)
ダントツはやはりGoogle
ほかにはMSMも

その他統計

使用しているサービス。まだAWSが多いのとGCPが意外と多い。

  • AWS (577)
  • GCP (335)
  • Azure (163)
  • etc: 194
  • オンプレ(OpenStack): 250
  • オンプレ(VMware): 149

CNCF Just Now

動画: 【CNDT-OSDT2019】CNCF Just Now by Noriaki Fukuyasu, The Linux Foundation - YouTube

(Graduatedに)CoreDNSというものがあった。しらなかった。
https://qiita.com/kanga/items/e74038f25d1f53ca6ade

CNCF Landscape
1000を超えるアイコン…3年前はもうちょっと見やすかったのだが。

k8s certification: 日本語での受講もできるようになった

Collaboration Without Boundaries(OpenStack Foundation)

動画: 【CNDT-OSDT2019】Collaboration Without Boundaries by Mark Collier, OpenStack Foundation - YouTube

日本に根付いてる。
9年目の誕生日を迎える。
OpenStack,最初はNTTからたくさんきてくれてた。

日本でカラオケ＆ネクタイを頭に巻きましたｗ

「国境を越えたコラボレーションは可能である」

木と木は根を通して通信してるらしい。OpenStachも同じ。
OpenStachはOSSのTop3に入る(他はLinux/Chronium)

クラウドのシェア

  • internal private
  • hosted private
  • public private

だいたい3割ずつ。

Performing Infrastructure Migrations at Scale(Airbnb)

動画 (コメント欄で教えていただきました！ありがとうございます)
Performing Infrastructure Migrations at Scale - Melanie Cebula, Airbnb - YouTube

こちらはKubeCon China 2019のものとのこと。(コメント欄にて指摘)

動画: 【CNDT-OSDT2019】Performing Infrastructure Migrations at Scale by Melanie Cebula, Airbnb - YouTube

Airbnb、70%以上がk8s
400以上がクリティカルサービス…？(聞きそびれた)

tech debt
「マイグレーション」によって効率を見直す

マイグレーションをうまくやっていくには

  1. マイグレーションをタイプ別に分類(コンポーネント・システム:CI/CDを変更するとか・インフラ:k8sに移行する)
  2. マイグレーションの順序・依存性 ： ： 10まである
  • cascading migration

non-cloud -> k8s
いろんな依存性がでてくる
段階を踏んでmigrationしていく。

  • riskの低いmigrationsからやっていく。
    依存関係のないものを独立でやることで効率があげられる。

  • 優先順位をつける。
    IaCから。

最初の７，８割はうまくいっても残りはうまくいかないことも。
うまいことコントロールしよう。

The 10 new rules of open source infrastructure(Canonical)

参考資料: (コメント欄で教えていただきました！ありがとうございます)
The 10 new rules of open source infrastructure

動画: 【CNDT-OSDT2019】The 10 new rules of open source infrastructure by Stephan Fabel, Canonical Ltd. - YouTube

  1. Consume unmodified upstream

修正されていないコードを使う

  1. Infrastructure-is-a-Product

インフラは製品
IaaSでも初期費が一番高くなる。

  1. Automate for day 1826

1826: 5年
5年後を完全に予測することはできない。
Livepatch(DeAN)稼働させたままカーネルのパッチをあてられるものがある。

  1. Run at capacity on-prem. Use public cloud for overflow.

きちんと設計してただしいH/Wを手に入れよう。
パブリック・プライベートクラウドの使い分け。

  1. Upgrade, don't backport

バックポートはしちゃだめ。
バックポートしようとすると手作りのインフラになる。それはプロダクトじゃない。

  1. Workload placemnent matters

何が起きているか、その時に知りたい。
アプリ層で起きてること・インフラ層で起きてること、その間のことを把握する。

  1. Plan for transition.

Edge

  1. Security should not be special

セキュリティは特別なことじゃない。
セキュリティを後付けするな。
最初から作りこむこと。ほかの非機能要件と同じ。

  1. Embrace shiny objects

新しくキラキラしたものを取り入れよう

  1. Be edgy, go Micro
$ snap install microstack --beta --classic
$ snap install microk8s --classic

Demand Less Choices!(IBM)

動画: 【CNDT-OSDT2019】Demand Less Choices! by Doug Davis, IBM - YouTube

Serverless
scale to 0まで落とせる。
PaaSだとそこが難しい

Knative
(demo)
1コマンドでpod/svcなど一気に作ってくれる。

kn service create myapp --image duglin/helloworld

[1HL] Kubernetes クラスタのポータビリティを保つための8原則

image.png

ポータビリティを保つための原則

検討中もおおいけど、本番導入してる人結構いる。

「ポータビリティとは」
クラスタ管理者にとってのポータビリティ。

なぜポータビリティが必要なのか。
クラスタ再作成の必要性に耐えられる。ベンダロックインもある程度避けられる。

ポータビリティの対象は。。

  • サービス
  • クラスタ管理
  • クラスタの仕様

インフラとしては、サービスのリソースは気にしない(アプリケーションエンジニアに任せる)
※アプリエンジニアがインフラをいじれることを前提

etcdのバージョンアップ
in-placeのアップグレードはリスクが高い→行わない
クラスタを再作成してそちらに引っ越すという手順を採用

しかし、40超えユーザ・300超えnamespaceで非現実

目指す世界

いつでも本番k8sクラスタを捨てられるようにする。
※ 必ずしもすべてのk8sクラスタが持つべき原則というわけではない(Wantedlyでは、という話)

コードベース

依存宣言

バージョンを固定する。「このバージョンを使う！」ということ。
新しくクラスタを作ったときにバージョンが異なると同じ動作ができるとは限らないため。

単一方向ビルド

コードベースの変更なしにクラスタを変えない。

非名前管理

podのsuffixのように、「この名前に依存したらマズそう」という名前を付ける。
DNSの場合は、CNAMEをつけて名前解決する。

キーを直接参照せずにワンクッション挟む。

重複欠損管理

これから作る場合は、jobの冪等性を保つなど、create and deleteで問題ない作りにしましょう。

教訓

複数管理することを想定しておくこと。
大規模になってから考えるのは難しい。

[1A1] Kubernetesクラスタの自動管理システムのつくりかた

インフラ刷新プロジェクトNeco

  • クラウドネイティブ技術をつかってサイボウズのインフラを刷新するPJ
  • 自社DCの1000台規模のサーバ上にk8sクラスタを構築

最高のインフラ

  • 高可用性
  • 信頼性
  • 高性能
  • セキュア
  • 安価

構成

  • GitHub
  • Quay

課題を解決するためのツールを作成
「CKE」

Cybozu Container Engine
なぜKなのにContainerなのだ笑

  • 構築だけでなく運用まで自動化
  • Declarative COnfigurationz
  • バックエンドはetcdとVaultを使用
  • Goで実装

既存ツールとの比較
k8s構築はいろいろあるが、運用の自動化までは対応してなかった。
Rancherは一部要件にマッチしなかった。
Secretリソースの暗号化など。

ツールの自作によってK8sクラスタの運用ノウハウ蓄積も狙い

CKE基本動作

管理サーバ: Vault + etcd
CoreOSで構築

workerは1000台規模

APIサーバのロードバランス

軽量TCPリバースプロキシ rivers を作成。
各ノード上にriversを稼働し、各ノード上からのapiサーバアクセスはlocalhostへの接続という構成

etcd接続問題:
ノードから「先頭の」etcdへのアクセスに失敗すると、なぜか接続できなくなる問題がある。
riversをかますことで、riversが落ちているetcdを回避して接続できるので問題回避できる。

運用の自動化

期待するクラスタの状態を宣言しておくことで、気体の状態と一致するように自律的にオペレーションを実施する。

秘密情報の管理

守るべき秘密

  • ssh鍵
  • CA証明書の秘密鍵
  • k8sのsecretリソース
  • 外部サービスアクセス用の鍵

HashiCorp社の秘密情報管理ソフトウェアのVault

Vaultの認証・認可

  • 多様な認証方式に対応
  • SSO, AppRole, K8s連携

k8sのEncrypting Secret Data at Rest
このDEKを暗号化するための鍵暗号化鍵(KEK)をどこに保存するかが課題。
cybozuではValtを使用。

クラスタ管理自身の冗長化

管理システムも冗長化しないと単一障害点になってしまう。
Vaultはetcdをバックエンドにし、HAモードを有効化する
CKEはいずれか1つのプロセスがリーダーとして実行

分散システム構築のおともにetcd
強い一貫性モデルの分散キーバリューストア

まとめ

つくるのはやはり大変。1年くらいかかった。
が、k8sにはかなり詳しくなれる。

k8sの自前で運用するのは非常に大変。
普通はやっぱりマネージドサービスの利用がお勧め

公開情報

[1B2]-1 Kubernetes拡張を利用した自作Autoscalerで実現するストレスフリーな運用の世界

image.png

k8s拡張のCRD/Custom Resourceを使用した事例。
CyberagentではGCP利用しているので、GCP前提の内容になっている。

  • Cloud Pub/Sub
    • GCPで提供されているメッセージングサービス
  • Cloud Bigtable
    • GCPのストレージサービスでスケーラブル・高いスループットのKVS
    • Autoscale機能はない

これらを組み合わせたアーキテクチャになっている。

Bigtableの遅延に対するスケールを手動運用してた。
遅延が解消したあとのスケールインも手動。
プログラムからscaleする機能はもともとあったが、Autoscaleはできなかった。
また、CPU/メモリ負荷だけでなく、リクエスト数などでスケールしたい。
これまではHPA(Human Pod Autoscaler)で対応。

そこで自作。

Gemini
k8sのCRDを利用したCustom Autoscaler

メトリクスの時系列データ、Stackdriver Monitoringと連携

Custom ControllerはkubebuilderなどのSDKは使わずにフルスクラッチ
(当時は情報が少なかったため)
deployment更新はkubernetes/client-go

なぜCustom MetricsでなくCRDを使ったか

  • Bigtableのノードのスケールにも対応させたかった(podのスケールトリガーだけでは不足)
  • 単純にCRDを使ってみたかった

Autoscalerの自作によってロジックやトリガーに柔軟性をもたせられるが、運用レベルになるまでの調整が大変。

[1B2]-2 adtech studioにおける CRD 〜抽象化したGPUaaSによる段階移行計画 & AKE Ingress v2～

image.png

スライド: https://speakerdeck.com/masayaaoyama/cndt2019-ca-k8s-gpuaas

コンテナ・アプリケーション実行基盤としてのk8s

X as a Service基盤としてのk8s

k8sは小さなクラウドに近い。

分散システムフレームワークとしてのk8s

期待する状態を記述しておくことで、あるべき状態に収束するように動作する

MLエンジニアが複雑なマニフェストを書くのは厳しい
MLTask CustomResource for GPUaaS abstraction（仮称）

Controller化することで、キャッシュを効かせたりいい感じにしてくれる。

[1G3] Operatorでどう変わる？これからのデータベース運用

image.png

k8s operatorを使うとどんなことができるのか・どんな点がうれしいのか

AmebaのオンプレK8sクラスタ：OpenStack上に構築。Kubespraydeデプロイ
DBはk8sクラスタ外にVMで構築

今ならDBをk8s上に乗せることもできる？
どんな方法がある？

コンテナでステートフルなアプリを動かすには

永続データをどうするか
アプリ固有の運用ナレッジをどうするか

の２点を考慮する

webのようなステートレスなものはスケールが簡単。ポータビリティも高い。回復力が高く、k8sと相性が良い

DBや分散システム、状態を持つアプリケーション

永続データ・名前の問題ふくめ、statefulsetを使って解決できる。k8s組み込みのリソース。

statefulsetによって、永続データの扱いは解決できる。
ではアプリ固有のナレッジは？？

k8s Operatorとは

運用上のナレッジがソフトウェアとして実装されている。
Operator自体もk8sでコンテナ化されている

ユーザはk8s独自のResourceとControllerで拡張できる。Operatorはこの仕組みを活用

実例 MySQL Operatorを動かしてみよう

oracle/mysql-operator を使用した、MySQL InnoDB Clusterのk8s環境へのデプロイ

お、これはcndjpのRDB特集でも扱っていたやつだ！
Oracle MySQL Operator 検証してみた

バックアップとリストア

  • kind: Backupリソースを使って作成。
  • mysqldumpを実行してくれる。
  • BackupScheduleで定期実行もできる
  • リストアも同様にkind: Restoreで行う。

障害発生時はどう？

primaryのpodが落ちた場合はクラスタから切り離され、secoundaryがprimaryに昇格する。
k8sが新しいpodを立ち上げ直し、データ同期が行われる。

nodeが落ちた場合、StatefulSetのpodは自動で再スケジューリングされない。
podのステータスはUnknownになる。
sprit-drainによる障害防止のため、再作成は行われない。

K8s Operatorのこれから

  • presslabs/mysql-operator
  • Vitess

その他にも、Operatorが存在するDBはいろいろある。

k8s operatorでNoOpsを実現？
システム運用保守で「嬉しくないもの」を取り除く活動

  • self healing 障害が発生してもサービス無影響＋自己修復
  • in-flight renewing
  • Adaptive Scale

自動化されたシステムはブラックボックスになりがち。
きちんと知識を持ったエンジニアは必要。
障害発生時に手がかりを残すための仕組みは必要（ロギング・モニタリング）
自動化が失敗した場合の手段は用意しておく。
最後の手段はやっぱり人手。

AWS Service Operatorなど、クラウド上のマネージドサービスを操作するOperatorもある。

全体的にわかりやすく説明されていて理解しやすかった。
恐るることなかれ! Cloud NativeリレーショナルDB特集!! - cndjp第12回に参加していて前知識が少しあった影響はあると思う。

[1C5] Prometheus setup with long term storage

image.png

スライド90ページくらいあるのであとで見返してください！

背景

メトリクスの必要性：
ユーザ環境のリソース利用状況はサービス側で監視。

時系列データベース

  • Head Block
  • Block
    • デフォルトでは2時間程度でストレージに保存

それぞれのBlockは完全に独立した時系列DBとして振る舞う。
meta.json内で重要なのは、minTime/maxTimeの「いつからいつまでのデータなのか」。

■ day2

[k2] キーノート

image.png

keynote (day2)
撮影時のシャッター音絶対NG！

楽天モバイル 完全仮想化クラウド型モバイルネットワーク

完全自動化されたOS
Rakuten Cloud Platform

試験環境・CI/CD
ベンダーのラボとつながっており、そこでテストしたものが商用ネットワークへリリースされる構成になっている。

草間さん、つなぎのトーク

CloudNative、コンテナつかえばクラウドネイティブってわけじゃないよね。
クラウドからクラウドネイティブって何が違うの。
クラウドを使っても、手作業でOSつくったりするとそれはプラットフォームがかわっただけ。
自動化・SRE
1箇所でも手作業が入れば、そこがボトルネックになる。
自分でぽちぽちプロビジョニングすると数分でも時間かかる。
そういったボトルネックをいかになくしていくのがクラウドネイティブでは重要

決済システムの内製化への旅

SB Payment Service

今回の資料じゃないけど、別の発表でのスライドあった
https://www.slideshare.net/makingx/springpcf-jsug-sfh1

今回のもアップされてた
https://www.slideshare.net/JunyaSuzuki1/springpcf-cndt2019-osdt2019-keynote

Springと
決済代行のお話

内製化に至る道

以前はほぼベンダ任せ。
運用の手作業も多かった。
→支援ツールの内製

  • Spring Boot
  • Selenium/Selenide

使用ツール

  • GitHub Enterprise
  • slack,Confluence,Jira など

サービス監視の質を高めるため、ElasticStackの導入。
監視用ダッシュボードを作成。

  • Elasticsearch
  • Kibana
  • Logstash

開発プロジェクトの支援
古いアーキテクチャが使われており、開発/リリースともに高コスト。システム監視も困難。

アーキテクチャをSpringベースに
- Spring Boot
- Spring Cloud

導入したもの
※CIをきちんと回す支援

  • Jenkins
  • Nexus
  • sonarqube

新システムに求めるもの
・スピード感の開発・リリース
・継続的な改善のサイクル
・監視が用意で障害に強い

これまではすべて開発ベンダに頼り切り。スピード感もでない

Pivotal Cloud Foundryを選んだ理由

プラットフォームに求めるもの
- リリースの改善
- クラウドのフル活用
- スケーリングやオートヒーリング

k8s or PaaS
学習コストや少人数の体制など、k8sはなかなか厳しい
すでに確立されたプラットフォームがほしい→PaaSを採用

Public Paas or Private PaaS
決済サービスのエンタープライズ領域など、privateを採用

Pivotal Cloud Foundryを使用。
Java/Springアプリの親和性
cf pushコマンドによるアプリリリース
Buildpackという仕組みでソースコードからコンテナイメージを作成してくれる。Dockerfileを書く必要もなし

プラットフォーム運用とアプリケーション開発者の責任分界もPivotal Cloud Foundryはきっちりしてる。
それぞれの作業に集中できる。
開発者は12Factor appに沿って開発。ベンダーロックインもない。

手に入れた開発/運用のカタチ

Circuit Brakerにより対象外性にすぐれた構成

CI/CDパイプライン
Concourse CI

Observability
参考:Metrics, tracing, and logging

  • Metrics: Graphana Prometheusなど
  • Logging: Elastisearchなど
  • Tracing Zipkin (初めて聞いた)

以前はログから可視化していたメトリクスについては
開発者はPrometheusを意識することなく、アプリをリリスすると自動で監視できる仕組みができる。

アクセスログ・アプリケーションログはKibanaで表示
開発者はElastic Stackを意識することなく、STDOUTへログを出せばOK
キーワード監視でSlack通知など

Zipkin
複数のサーバにまたがる処理でも、どこの通信やSQLかひと目でわかるようになる
サービス目線のモニタリングが大事

外注にたよりきった開発を積み重ねてもプラットフォームは構築できない。

金融領域におけるOpenStack導入事例の紹介

YJFX (Yahoo Group)

システム構成
Front system・Analyze SystemにOpenStackを導入（客から見るとバックエンド）基幹系

なぜ導入したか
本番・STG・開発、パブリッククラウド使っていた。
- コストの問題
- 金融系はやりたいことが増えるだけで、必要リソースは増えるばかり。
- デリバリの問題
- アプリのリリース、インフラTに依頼して構築、オーバーヘッドがあった
- 使用前に申請的なこともあり、クラウドの意味とは・・・

導入時のGood Point
※ペットから家畜

  • Ansibleの活用
  • 100台のサーバを30分で構築

逆に、Ansible活用できていないレガシーシステムの以降は苦労する。

  • import/export
  • device mapping
  • Network Configuration

トラブルシューティング
RHのサポートが待てない・・・

  • ドキュメントの戦い
    • ドキュメントが間違っている
  • ソースコードこそがすべて

OpenStackの導入によって、Red Hat Summit 2019の登壇の機会
→ レガシー派のメンバや経営層からの評価がかわった。

真のCloud Nativeになる
単にクラウドを使っている状況からの脱却
どうクラウドにするか。用途に合わせたマルチクラウド設計
クラウド前提としたアプリケーション含めたアーキテクチャ設計
コンテナ・運用自動化・オーケストレーション

レガシーシステムのモダナイゼーション

すべての技術負債をすぐにどうこうすることはできない。（いま作ってるものが、将来技術負債といわれることも）
システムは経営の問題を解決するものである。
経営の課題ってなんだっけ？それを解決するには？
こういうことに取り組む。

エンジニアリングだけ成功してもだめ。
経営・サービス企画の意識改革も必要。

Change the game, Change the world

RedHat北山さん

k8sはプラットフォームを作るためのプラットフォーム、と最近言われるようになった。

プラットフォームとは・・・
企業やユーザが提供する製品・サービス・情報と一体になって初めて価値を持つ製品やサービス

プラットフォームを利用するコストよりも得られる価値が大きくなければ使われない。

  • Velocity(迅速性)
  • Self-Healing(自己回復性)
  • Abstraction(インフラの抽象化)

k8sの利用によって、クラウドリソースが抽象化され、運用工数を下げられる可能性はある
ただし、技術力や情報が少なくても利用できる、というものではない

+Native
運用工数を下げるためのポイントが、既存すステム運用とは大きく変わるという意識改革
・クラウドに使われるのではなく、クラウドの運用方法に自らを変えていく

Operator
運用の知見をコード化し、アプリケーションの運用を自動化する

  • OpenShift4はOperatorHubと連携
  • OpenShiftで見えるOperatorはRH認定

Operator Framework: Operatorsと呼ばれるk8sネイティブアプリケーションを効果的に開発できる
OperatorSDK

OpenShiftのドキュメントにも載ってた
- 第40章 Operator Framework (テクノロジープレビュー) のインストール - Red Hat Customer Portal (OpenShift 3.11)
- 第9章 Operator SDK - Red Hat Customer Portal (OpenShift 4.1)
- 2.1.2. Operator Framework

Couchbase Operator
OperatorをOperatorで管理する

OpenStackを用いたパブリッククラウドの国内事例と課題

お名前.com レンタルサーバもOpenStack

2019年にリリースしたクラウドサービスはOpenStacではない独自基盤

[2B1] 実録！CloudNativeを目指した230日

image.png

230日とは…JKD v18.12からの日数

  • Beremetal Era

    • サーバ投入のリードタイムがボトルネックだった。
      • サーバのサイジング
    • 作業するエンジニアのアサインやキャパシティプランニングが難しい

  • Cloud Era

    • OpenStackを用いたプライベートクラウドへ
    • 物理サーバの管理を集約することで効率UP

仮想化されているとはいえ、設計・構築は時間はかかる。
普段アプリ系の人間であればやはり難しい。

  • クラウド化しても、存在する課題

    • 人が介入するとやはりボトルネックになる
    • 自動化されてない箇所はオペレーションが必要

  • 解決するには？

    • IaaSのまま自動化をすすめる(OpenStack Heatなど)
    • IaaSを隠蔽するようなプラットフォームを導入(CaaS/PaaSなど。ただし管理するレイヤーが増える)

そこでk8sを導入

「k8sって、運用大変なんでしょ？」

導入できても運用で疲弊すると、本質的な課題解決にはならないのでは？
→もし力尽きても全くの無駄にはならない

コンテナ化による技術の蓄積
ポータビリティ性により、マネージドサービスへ移行もできる

なぜ共用クラスタから始めたのか

IaaSとk8sでは考え方がかなり違う。やはり学習して慣れていくしかない。
minikube、kindなどいまはいろいろある。
興味を持ったときに、すぐ触れるクラスタがあるべき

minneへのk8s導入

問題発生時にすぐに切り戻せる体制で導入

Consul Kubernetes Integration

Consulのサービスとk8sのサービスを相互に同期
podが動いてるnodeのIPをnode

(んー、OpenShiftの外部LB+router podに近いかんじかな？)

既存システムにトラフィックも流せた。完了！

・・・とはいかず。
k8sへトラフィック増やしたら、特定podへの付加集中がたまに発生

  • どうやって被疑個所を絞り込むか
  • 絞り込んだ後の原因特定をどうするか

特定のpodに偏るということはLB周りがあやしい。
トラフィックを見てみよう。
Prometheus+Grafana

結果、ルーティングがやはり怪しい。
では、ルーティングの仕組みはどうなっているのかを調査。

balancer.balance()
- luaを使っている
- RoundRobin(default)とEWMAが使用可能

ingressのpod数が多いと発生すると可能性がある
nginx-ingressのpod数が多いと、Serviceのendpoint更新時に全ingressにアドレス一覧が反映されるが、それまでのRoundRobinの状態がリセットされ、トラフィックの負荷分散が初期値に戻る…なるほど

CloudNativeになれたか

まだ過度期である！

「手作業でできないことを自動化するのはとても難しい」
基盤サイドとしては「抽象化されたプラットフォームの提供・考え方の啓蒙」
k8sになると「1インスタンス1ロールでなくなるので問題児の原因特定が難しくなった」
可観測性・Observabilityの強化し、調査ポイントを絞り込めるようにすることが重要

[2H2] Rancherで実現するKubernetes Everywhere

image.png

Genericな話をします。
明日渋谷でRancher Dayやります。

k8s,k3sがホット
今から始める人はk3sから！

もともとRancher Linuxというディストリつくってた。
GUIの管理ツール

Lightweight Kubernetes

curl -sfL https://get.k3s.io | sh -

クラウドじゃないけどk8s使いたいとき。
Launcher一択という人はおおい。

k3s
Edge側にも入る。
Launcherは統合開発プラットフォーム

RancherのGitHubのStartは12000弱
Helmに近い

レガシーなものをコンテナ化する際にLauncherの選択肢
20年たってるものをコンテナ化…

ディズニーの映画配信はLauncher

さまざまなk8sを一元管理する、それがLauncher

  • RKE(オンプレ)
  • EKS
  • GKE
  • AKS

機械学習の基盤としてのk8s/Launcherの問い合わせがとてもおおい

Kagoyaのコンテナサービス。近日リリース予定。
他社クラウド・オンプレもノードとして追加可能
Rancher管理サーバ1台・ノード1台から開始可能

サポート
https://rancher.com

[2C3] クラウドネイティブ技術を創る技術

image.png

haconiwa
柔軟な設定・hookなど をrubyで記述できる。

  • なぜk8sではないのか？
  • k8sとマネージドクラウドの違う

UI/UX

マネージドサービスはバックエンドを意識する必要がない。
k8sはある程度は必要

API&Scheduler

CMDB: PostgreSQL＋Peacemaker

Apache Kafka
高速処理が可能なメッセージングシステム

[2E4] あなたのk8sは大丈夫？k8sでできるセキュリティ対策

image.png

  • セキュリティおさらい
  • CIS Benchmark for k8s
  • Secret管理

セキュリティおさらい

コンテナセキュリティのレイヤー

  • 実行基盤
  • ベースイメージ
  • アプリのセキュリティ対策

実行基盤

  • SELinux
  • capability
  • rootコンテナ
  • 特権コンテナ

ベースイメージ
野良イメージに注意

  • マルウェア入ってない？
  • コインマイナー入りだったりしない？

アプリレイヤー

  • アプリ・ライブラリに脆弱性ないですよね？

まとめ
リスクとアジリティのバランスをとる
コンテナセキュリティは3層で考える

CIS Benchmark for k8s

CIS Benchmarkとは：Cybersecurity Best Practices
パブクラやk8s、OSにおいて「ここはこうなっているべき」というプラクティス集

kube-bench
動かし方
k8sのホストマシンにバイナリ落として起動。--pid=hostオプションつけ/etc、/varをread-onlyでマウントしてコンテナ実行
k8sで強い権限がある場合: job-master.yamlとjob-node.yamlをapplyする
簡単に実行できるのでさくっとスキャンしてみるのはいかがでしょう？(すべて対応する必要はないが)

Secret管理のためのSealedSecret

・k8s secretはただのbase64
・最近はやりのGitOpsと相性悪い

というわけで、Secretを暗号化してCRD「SealedSecret]を作成。helmでインストール可能(1コマンドで入れられる)

SealedSecretの問題点
暗号化されてるとはいえGitに入れたくない場合
Secret管理できるツールない？

ということで、HashiCorpさんのVault

Vaultで解決できること

  • 各種Secretの一元管理
  • 期限付きキーの発行
  • 暗号化APIの提供
  • 暗号化キーのろーてーと

メリット

  • Secret情報へのアクセスログの集約

考えること

  • 可用性
  • 性能
  • Auditログ

構築で考えること

  • Sealing
    • Sealingするとアクセス不可に
  • Storage
  • HA-Storage

Valtでクラスタ: Active-standbyで、standbyへのアクセスはactiveへリダイレクトされる。
有料版はレプリカ機能もつくらしい。札束で殴れ。

Auditログ
出力先は3type

  • File
  • syslog
  • socket

k8s上にvault立てる場合はsidecarなどで。

Vaultを使う目的を再確認

  • k8s管理者はsecretを見れるべきではない
  • Vaultを入れることでOpsがやりにくくなってほしくない

そこで、k8sのServiceAccountを使ってvaultにアクセスする。

Vaultアクセスライブラリ

  • Official
    • vault go client
    • vault ruby client

[2G5] [ライブコーディング]Custom ResourceとControllerを作ろう

image.png

対象:

  • k8s完全ガイドは読んで一通りk8sわかるひと
  • CRDはまだの人

もくじ

  • k8sのControllerとは
  • CRDとCustom Controllerとは
  • 本日作るCRDとCustom COntrollerの概要

k8sのControllerとは

k8sのドキュメントより。
現在の状態をみて、理想的な状態にいいかんじにする処理をループでまわす。
理想の状態に一致させる「なにか」

現実世界の例
エアコンのリモコン
ユーザが25度に設定すれば、エアコンがその設定を維持する
ユーザは宣言するだけ

「何か」 Control Loop
Act -> Observe -> diff ->

CRDについて
ReplicaSetやDeploymentみたいなリソースを自分で定義できるもの
CRD+Custom COntrollerを使って、k8s nativeなアプリ(Operator)の開発が可能

詳しくは @Ladicle先生のQiita記事

実際のk8sコントローラと同様のフローで開発しようと思うと、お作法がたくさんでくじけるｗ
便利なフレームワーク・SDKがある

kubebuilder

こんなの作るよ

apiversion:
metadata:
    kind: WebServer
spec:
    replicas: 3
    content: Hello, CNDT!
    port:
        http: 8080

この1個前に、プロジェクトのinitialize

kubebuilder create api --group servers --version v1beta1 --kind WebServer

ひな型をビルドされる。
今回はサーバーグループ

お作法的にはαだけど、青山さんもv1beta1を指定とのこと。
きのう・一昨日くらいにbeta2が出たらしい

type WebServerSPce struct {
    Replicas int32 `json:"replicas, omitempty"`
}

大元は↓にできてる。↑にSpecの構造を追加する

type WebServer struct {
    :
    :
}

んで、

$ make manifests

config/crds以下に定義が生成される。

webserver_controller.go
実際にコントロール処理を行う処理がここに実装される。
Reconcileメソッド。

この処理が、webサーバの情報がインスタンス変数をgetしてもってくる。
.Deploymentでdeploymentを処理。

本当はReconcileの中を作成していくが、DeploymentのPodTemplateSpecのなかを編集していく。
今回は、`/bin/sh -c echo で nginx/index.html にstaticなhtmlファイルを生成

DeepEqual(deploy.Spec, found.Spec)
デプロイが定義、foundが現在の状態。
差異があれば定義の状態になるように変更を書ける

make docker-build

make install
make deploy

port設定の追加
入れ子の構造体で定義

make manifest

Deploymentを作るコードはある(作った)ので、今度はServiceを作るコードを作ります。
SetControllerReferenceを使って関連付けを行う。
サポートに聞いたmetadataにあるReferenceのやつかー

特定のイベントが発生したとき
EventResourceを使って作れる

ライブコーディングの流れはGitHubに用意
https://github.com/cloudnativejp/webserver-operator

所感とか…

Custom Controller周り、過去のKubernetes Meetup #18ではControllerやCRDを全く知らずに参加して瀕死の重体になったりしたけど、何度か発表を聞いていたおかげで、何をやっているのかはついていけた。
が、meetupのあとに自分で手を動かして試したりすることを結局しなかったので、さすがにそろそろやってみたい。
あと、Go言語。
ライブコーディングも面白かったのでリポジトリをチェックしよう。

Operatorの話もかなり増えた。OpenShift Meetupなど各meetupでも盛んにOperatorの話が盛り上がっていたのを聞いていたので、やはり事前知識が少しあって助かった。MySQL ClusterなどはCloud Native Developers JPでも聞いていたので、とてもわかりやすかった。

昨年12月のJapan Container Days v18.12のときにくらべて「クラウドサービス提供しています」「社内にクラウドサービス構築して開発/運用やってます」が増えた印象。
(あとでよく考えたらイベント自体がOpenStackでもあるので当然ですね…)

あと、冬のJKDでノートPCのバッテリが終日イベントは持たないことはわかっていたので、Androidタブレット用のBluetoothキーボードを調達して持ち込んだら、ノートPC＆タブで1日キーボードでメモ入力できて非常によかった。

30
24
5

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
30
24