2018-12-04 JapanContainerDays v18.12 Day1
2018/12/04 に開催された JapanContainerDays v18.12 Day1 のイベントレポートです。
●イベントのテーマ
JapanContainerDays（JKD）はコンテナ活用/クラウドネイティブの現状をひとまとめにした開発者のためのイベントです。コンテナエコシステムを形成する数多くの技術やソリューションを歓迎します。
■Evolving Cloud Native Landscape
CNCF
●CNCF Project Maturities
・アーリーマジョリティに届いたらGuraduated
●Cloud Native Trail Map
・https://github.com/cncf/landscape
●From Virtualization to CloudNative
・2000: No-Virtualized Hardware
・2001: Virtualization
・2006: IaaS
・2009: PaaS
・2010: OpenSourceIaaS
・2011: OpenSourcePaaS
・2013: Containers
・2015+: CloudNative
●What's next
・linuxと同じ広がり方をするはず
・Cultivate Projects + Fill the Cloud Native Gaps
●IoT + Edge + Kubernetes
・KubeEdge
●Serverless
・CloudEvents
・Virtual Kubelet
●Network
1.0: Separeta physical boxes
2.0: VNF(Virtual Network Functions)
3.0: CNF(Cloud-native Network Functions)
VNFはKubeVirt/Virtletで動く
2019年は、KubernetesのイベントをTokyoで！
■Microservices on Kubernetes at Mercari
Mercari
●Why Containers?
・マイクロサービスで小さく、独立したチームが作れる
※適切な権限もセットで
・安全なリリースで安心して開発できる
・Imutable Infra
・Deterministic Deployment
・vs. VM
・faster build & boot
・high portability
・better utilization
VMだとリソースに余剰が出ちゃう
●Why Kubernetes?
・Kubernetesがやってくれないこと
・deploy / build
・Application-levelのサービスは連携しない
・logging, mmonitoring, alerting
・configuration language
→この辺りを提供してくれているのがPaaS
・Extensibility
・Custom controller
・Custom Resource Definition
・Ecosystem
・抽象化レイヤに分かれている中で、ユーザが拡張できる部分
・Knative, Kubeflow... 自由に選べる、つくることもできる
・作って参加できる！
・Certificate Expiry Monitor Controller
■Kubernetesによる機械学習基盤への挑戦
Preferred Networks
●PFNの研究開発環境
・日本で最大のオンプレGPUクラスタ
●なぜkubernetesか
・セキュリティ
・スケジューリング機能
・拡張性
・OSSでエコシステムが充実
●機械学習基盤の要件と実現方法
・多様な研究環境
・ホップ数の少ないノード割り当て
・小さなデータはNFS、大きなデータはHDFS
・スケジューリング
・マルチテナント
・NamespaceごとのPrometheus
・自由度の担保
・グランドチャレンジ
全リソースを集中
週末とか
●今後
・kubeflow
■LINEエンジニアを支えるCaaS基盤の今とこれから
LINE
●LINEの基盤
・IaaSの品質 != Applicationの品質
・スキルレベルが違うからPaaSで底上げ
●LINEのPaaS
・すべてのユーザをサポートする予定だった
→PaaSの限界
→野良Kurbernetesの乱立
●KaaS
・運用コスト削減
・洗練されたKuubernetesの提供
●FaaS
・Serverless
・Event駆動
運用自動化、Bot、Webhookが最適だね
Knativeにk8sのイベントをつなぐEventProviderを作っている
●これからのCaaS
・CaaS Family
・PaaS
・FaaS
・KaaS
・IaaS
利用者の事情や状況によって使い分けるので、どれも伸ばしていく
■Cloud Nativeの未来とIBMの取組み
IBM
●IBMはOpen Technologyで、Cloud Native Companyを目指す
・システムを絶対止めない -> ビジネスを絶対止めない に変わった
・社内でも大規模にKubernetesを利用している
・プロダクトをContainerize, Kubernetes最適化
●悩み事
・kuberntesクラスタはどんどん増える
・IKS
・ICP
・人を育てる
・IBM Cloud Garage
・DesignThinking
・アジャイル開発手法
・IBM Cloud
・マルチクラウド
・Multicloud Manager
■クラウドネイティブで作る、新しいクルマの世界
デンソー
●なぜクラウドネイティブ？
・事業会社 & Cloud事業者 の2レイヤになって、スピードが上がった
・ハードウェアメーカーはハードにこだわって、破壊的イノベーションに対応できなかった
●デンソーの挑戦
・クラウドネイティブを活用しITサービサーへ
・デザイン思考、サービスデザイン
ゼロからイチを創る
・Cloud/OSS
早く作る、安く作る
・アジャイル開発/DevOps
作りながら考える、顧客と共に創る
●Data Management Layer
・Message broker
・Data Lake
・Data Mart
●Microservice Layer
・社内のリサーチャーが、自分が便利にする仕組みを作る
-> これをRESTでラップして、ユーザ提供
●Application Integration Layer
・アプリをconductorのworkflowで構成
■ZOZOTOWN システムリプレイスにおける Kubernetes活用
ZOZOテクノロジーズ
●ZOZOTOWNのシステムリプレイス
・問題点
・HWリソース確保
・モノリシックなアプリ
・手運用
・public cloud移行
・最新技術を利用
●Kurbernetes導入
・課題
・手作業
・スケール
・運用負荷を減らしたい
・Azuureで動いている
・ACS
・AKS
・ACS Engine
●使っているもの
・安全にデプロイ
・namaspace
・安定稼働
・セルフヒーリング
・水平オートスケーリング
・Azuure仮想マシンスケールセット
・Kubernetesクラスタを分散
・デプロイ
・Canary
●まとめ
・サービス信頼性の向上
セルフヒーリングで安定
・運用負荷の低減
手動 > 自動で楽に、安全に
■基調講演まとめ
2019年 から CloudNative Days に!
■コンテナネットワーキング（CNI）最前線 〜比べて分かるFlannel, Calico, Canal, NSX-T 〜
進藤 資訓さん（ヴイエムウェア）
●DockerNetwork
・構成
docker0 - veth - container:eth0
・課題
複数ノードだとport-forwardが必要
→CNM
→Docker依存 & 複雑で、Kurbernetesには採用されなかった
●CNI
・コンテナのライフサイクルに合わせてネットワークリソースも管理
・現在のスコープでは、ポリシーの話は入っていない
・3rd partyプラグイン
Flannel, Calico, Canal, NSX-T
●Kurbernetesがネットワークに求める要件
・コンテナは、他のコンテナとNATなしでつううう心できる
・ノードは、コンテナとNATなしで通信できる
・コンテナから見える自分のIPアドレスと他から見た場合が同じ
●Kubernetesのネットワークモデル(ノード内)
・構成
Node > Pod1:eth0 > container内はloopback
●flannel
・機能
ネットワーク接続性
・特徴
バックエンドのサポートが多い
・動作
vxlan > iptables > arp
●calico
・機能
ネットワーク接続性
ネットワークポリシー
・特徴
複数のオーケストレーションに対応
ポリシーはiptablesで実現
ポリシー部分だけ使う事もできる（canalなど）
・ネットワークポリシー
ポッド単位にラベルベースで定義できる
iptablesと格闘が必要
●canal
・calicoのポリシー + flannel
●NSX-T Container Plugin(NCP)
・機能
ネットワーク接続性
ネットワークポリシー
その他
・特徴
ネームスペース連動
可視化&トラブルシュート機能
※iptablesは問題が多い
・件数が多いと性能
・ルールの数が多いと反映にも時間がかかる
●まとめ
コンテナ・ネットワーキングは闇が深い
動きが早いので、webの情報が信用ならない
PoCならどれでも大丈夫。規模を大きくするなら注意しよう
■本番環境のKubernetesマニフェストに最低限必要な7のこと
青山 真也さん（CyberAgent）
●コンテナのライフサイクル(起動時)
・初期化処理あり
1. Entrypointで事前処理
shellscript
設定ファイルにパスワードを埋め込んで起動など
2. Init Containerを利用する
共有volumeにデータを準備する
不要なコンテナをメインから除外
3. Sidecarパターンでデータを更新する
基本的にはInit Containerと同じ、継続的に更新できる
4. postStartスクリプトをリヨすうる
メインプロセスを実行直後に、同一コンテナ上で起動される
・まとめ
メインコンテナにプログラムが必要か？
起動前に実行する必要があるか？
●コンテナのライフサイクル(停止時)
・restartPolicy
・Always
・OnFailure
・Never
※DeploymentはAlwaysのみ。jobだと使える。
・コンテナ停止時の挙動
・serviceからの除外処理
・preStop
・SIGTERM: terminationGracePeriodSeconds=デフォルト30秒
・SIGKILL
・まとめ
ログの終了処理とかで調整するが、短く終わるように分散させたほうが良い。
早く落とせる設計が必要
●ヘルスチェック
・libenessProbe
check失敗 > コンテナを停止
メモリリーク、復帰が難しいなど
・readinessProbe
check失敗 > serviceから除外
service-inできるかどうか GET /status, GET /cache など
・停止しやすいコンテナ
「kubectl drain」でメンテナンスできる
パーセンテージ指定でPDB(PodDisruptionBudget)を使える
-> メンテナンスししやすく
●スケジューリング
・主なスケジューリング方式
1. 簡易的な NodeAffinity(nodeSelector)
2. Node Affinity / Node Anti-Affinity
特定ノード
3. Inter-Pod Affinity / Inter-Pod Anti-Affinity
特定Podがいる範囲
NodePool / Instance Group などの指定
●リソースの割り当てと基準
Limits: 使用上限
Requests: 使用下限
kurbernetesがスケジューリング時に見る
ClusterAutoscalerはPending status のPodがいたら動く
・まとめ
Requests / Limits の差がなるべく開かないようにする
完全に一致させると、停止を後にしてくれる
・LimitRange
最大 / 最小の割り当て量
デフォルトのリソース割当 ※やる
requests / limits の差の上限 ※やる
●カーネルパラメータのチューニング
・securityContext.sysctls
・コンテナ間で共有だから設定がある（safe / unsafe）
●インターネットに公開するサービスのアクセス制限
1. type:LoadBalancer Serviceでの制限
2. Network Policyでの制限
Nodeごとのiptables
リソースを使う
3. Ingressでの制限
betaなのは実装がバラバラでまとめられていないから
GCPの場合、BackendConfigでCloud Armorが連携
●まとめ
こまかいところは本を読んでねw
■40 topic of Kubernetes in 40 minutes
寺田 佳央さん（マイクロソフト）
●コンテナ関連
1. Dockerfile
・小さいイメージ
・マルチステージビルド
2. build, tagging, push
・毎回一緒なのでスクリプト化
・deployment.yamlもsedしてしまっている
・docker registoryへのsecretを登録
3. kubectl apply
4. kubectl get po -w
5. kubectl describe po ID
6. kubectl logs ID
7. kubectl port-forward ID 8080:8080
localで動作確認するなら、これが王道
8. kubectl explain deployment.spec
yamlの定義で何が書けるかが見れる
9. kubectl get po --v=9
10. serviceを定義
selector大切
11. 一時的に書き換えるなら
kubectl edit selector名
type:ClusterIP -> LoadBalancer
※ほんとはだめ
12. 外部公開するためにingressを当てる
serviceは内部向け
13. RESTで操作すれば管理アプリを自作できる
14. ConfigMap
15. kubectx で複数k8sクラスタを切り替えよう
16. ~/.kube/config は 環境変数:KUBECONFIG で指定できる
●コンテナ関連の注意点
17. latest tagは使わない
18. タグには buildIdを使う
19. 小さなサイズのイメージを作る
multi stage buildを使う
ユーザのパーミッションを設定
20. DockerHubのイメージは信用しない
セキュリティチェックをかます
●Kubernetesの基本
21. 最新の情報を追う
22. リソース使用量を指定しよう
23. selector と labelの理解は大切
24. serviceでLoadBalancerは使わない
25. こまったら
describe, logs, exec -it, get events
●Kubernetes運用のアドバイス
26. すべての機能を利用する必要はない！
27. 複雑な構成を作らない
RBACで権限管理とか、やる？ 分ければ良くない？
28. LBもPVも実装依存
29. バージョンごとに設定や機能の差があるよ！
30. 大規模でクラスタを作らない
ものりすといっしょだ！
31. version upは注意
新しくクラスタをつくる！
32. Persistence Volumeは極力使わない
バグ多い
33. ManagedDBを使う
●AKS
34. 簡単に使い始められる
35. remote debugできる
36. monitoringついてる
37. kube-advisor
38. devspaceでCI/CDが数クリック
39. k8s以外の選択肢も考える
他にも色々あるね
serverlessとかも
40. 道具を適切に使っていこう！
●githubにノウハウまとめてます！
https://github.com/yoshioterada/k8s-Azure-Container-Service-AKS--on-Azure
■Ansible、Terraform、Packerで作るSelf-Hosted Kubernetes
高石 諒さん（GMOペパボ株式会社）
●Kubernetesクラスタを自分で構築したい。なぜ？
・社内のインフラ
・OpenStackベースのPrivateCloud
・ハイブリッドクラウド構成のサービスもある
・PublicCloudにある、より効率的に開発できるぷるエットフォームがない
・CaaS/PaaS/FaaSを提供して生産性UPしたい
まずCaaS > Kubernetes
・どう構築 / 運用するか？
Kubernetesの運用で消耗するのは本末転倒
Self-Hosted Kubernetesはどう？
Kubernetes自身に自分自身を管理させる
Kubernetes as a Serviceとは違って、単一で、自分を管理
●Self-Hosted Kubernetesとは何か
1. Small Dependencies
kubeletで各コンポーネントを動かす
Docker, kubeletのみsystemdで管理
2. Deployment consistency
ファイルとして置くものだけSSH
3. Introspection
kubectl logs などのAPIでコンポーネントのデバッグや調査ができる
4. Cluster Upgrades
API経由でクラスターのアップグレードができる
アプリと同じ方法
5. Easier Highly-Available Configurations
外部ツールなしで、監視やHA構成
アプリと同じ方法！
●どうやって作ろう？
・bootcubeとかでも良い
・これまでのノウハウを生かしてみた
・2-4 cluster
kubelet: systemd管理下
etcd: static pod
・Packer
ベースイメージにDockerやkubeletなどのインストール
・Terraform
サーバー、証明書発行
・Ansible
クラスター構築、更新
DynamicInventory
●構築の流れ
1. Packer / Ansibleでベースイメーい作成
2. Terraformでサーバ起動
各種証明書、鍵の発行
3. Ansibleで、BootstrapClusterを起動
etcdクラスタ
Static Pod
マニフェストファイルのパスを監視
ファイルのライフサイクルに合わせてPodを作成、削除
apiserver, controller-manager, scheduler
4. Ansibleで、BootstrapClusterから、Self-Hosted Clusterに切り替える
kube-proxy, flannel
apiserver, scheduler, controller-manager
-> bootstrapのapiserverを、マニフェストファイルで削除
-> Self-Hostedのapiserverがリトライで上がってくる
●学びと課題
・自分自身を管理する を理解できた
・クラスタの上/下両方の知見を同時に得られた
drainしないと大惨事
・Dockerやkubeletの更新をどうする？
ansibleで1ノードずつ サービスアウト & 更新 & サービスイン
・ノードの増減をどうする？
Terraformでノードの増減は可能
●まとめ
・構築までは行ける
・ノードの入れ替え、コンポーネントの更新は大変
・CustomController化
■ABEJAの映像解析を支える仕組みとRancher
大田黒さん（ABEJA）
●ABEJAの紹介
・ABEJA Platform
・Pipelineで学習のライフサイクルすべてをつないでいる
1. Data collection
2. Annotation
3. Training
4. Inference
5. Re-Training
・PaaS
・AQBEJA Insight for Retail
カメラ、POSデータから施策を練る
リアル店舗のGoogleAnalytics
複数台カメラのデータを紐づけて、入店〜退店までの動線を分析
●バックエンドの紹介
・バックエンドの役割
・データデリバリー観点
・運用観点
・構成
・カメラ > 録画システム > ABEJA Platform
・録画がRancher上で動いている
・暗号化接続終端コンテナ
・録画コンテナ（カメラごと）
・動画変換コンテナ（カメラごと）
など
●ABEJAでのRancherの活用
・DockerSwarmから移行
・CLIのみ
・インフラ知識が必要
・採用の決め手
・構築が簡単
・既存コンテナをDockerComposeに書き直したら移行できた
・WebUI
・周辺システムともつなげやすい
・やっていること
・論理リージョンを分けて、Rancherクラスタを複数立てている
・Terraformで建てられるようにしている
●DS基盤としての利用
・データサイエンティストが自力でRancherを立てて、使ってた
・DASKの分散アプリをRancher上で動かしている
■Rancherで実現するManaged Kubernetes Service in LINE
西脇さん（LINE）
●Rancherの採用まで
・理想と現実
・2018年6月〜
・0.6人月 x2人
・Kubernetesで考えることがいっぱい
・OSS利用へ
MAGNUM: 制約が強い。導入が難しかった。
Rancher: ゆるい制約。導入実績があった。
・OSSは利用するが、OSSは信用しすぎない
Blackboxにしない
コードを確認する
コントリビュートもする
●Rancherをどのように利用しているのか
・Rancher2.x
・Kubernetes Operator Patternを使ってCluster/Nodeを構築
・Rancher+αでManaged Kubernetes Serviceを実現
・API Server
PrivateCloudとの連携
Rancherの機能を制限
複数RancherCluseterをつなぐ
・Rancher
利用機能も
・Rancherに期待していること
×：Kubernetesを簡単に利用できるようにする
◯：運用を楽にする
・Rancherをビルドして使っている
・パッチだけを管理
・JenkinsでCI/CD
・当てているパッチ
・バグフィックス
・内部のステートをモニタリング
・/metrics を見れるようにカスタマイズ
・そのままだとログでしか見れない
●重要な内部ステート
・Kubernetes API Latency
内部データはすべてKubernetesで管理しているので、直接影響
・WebSocket Session Informations for Agents
すべてのRancher Agentは、ServerにWebsocket Sessionを確立
ここが途切れていると正しく状態を見れない、更新できない
・Handler Total Execution / Total Failure
Norman Frameworkでk8s Custom Controllerを実装している
ここを監視すればRancher内部での動きをすべて把握できる
・Each Controller's Queue Metrics
Norman Frameworkはclient-goのラッパー
ここのQueueでつまり具合が把握できる
●Rancherを採用してみてどうだったか？
・リードタイムをかなり短縮できた
・ドキュメントが少ない
・クラスタ数増加でタイミング起因のバグもあった
●これから期待していること
・100, 1000 クラスタの管理を見据えて自動化
・スケーラビリティの改善
■2019年はコンテナよりもクラウドネイティブ!? Knativeのすべて
草間 一人（Pivotalジャパン）
●コンテナは楽になった？
・まだまだkubernetes使うのは面倒
●クラウドネイティブ時代に行こう
・クラウドネイティブなテクノロジー
コンテナ
サービスメッシュ
マイクロサービス
イミュータブルインフラ
宣言的API
：
・世の中の興味の流れ
Docker > Kubernetes > CloudNative
コンテナつらい
Kubernetes難しい
ここにサービスメッシュ？
Knative！
●Knative
・読み方は、ケイネイティブ
・Google / Pivotal / IBM ...
・テクノロジースタック
Kubernetes
Knative
Istio
●Knativeでは何ができるのか
・一段上の抽象化
・Kubernetes
コンテナを作ろう
NWを作ろう
・Knative
Serviceを作ろう
・CustomResources
・KnativeはCRDモンスター
・knctl
knctl deploy -i IMAGE_NAME -s SERVICE_NAME
knctl route list
knctl rollout
●まだ楽になりきってないのでは？
・Dockerfileどうする？
・これまでのCaaSのワークフロー
・Dockerfile
・docker build
・docker tag
・docker push
・Deployment.yml
・Service.yml
・kubectl deploy Deployment
・kubectl deploy Service
・Knative
・Builds
・Eventing
・イベントドリブンなアーキテクチャ
・KnativeのServerless ≠ FaaS
・Kwsk: OpenWhisk on Knative
■感想
Container / Kurbernetes は環境として利用できるのが当たり前、その上でどれだけ簡単に利用できるかの話がメインになったんですね。お話を伺っていて、ワクワクが止まりませんでした！
普及した分、リテラシーの底上げも必要になってきているのですね。先頭を走っている皆さんのお話を聞いていて、前回と話の展開が変わってきたのを感じました。
明日も、どんなお話を伺えるか、とても楽しみです！
The Agile Guild(TAG) Advent Calendar 2018 4日目の記事として書いてみました。
> TAGに参加する
> TAGに相談する
どちらも、こちらのページから。
Day2 の様子はこちら
この記事が参加している募集
いつも応援していただいている皆さん支えられています。