JTF2020参加レポート
はじめに
- JTF2020に参加させていただいたときのメモです。
JTF(July Tech Festa)とは
- インフラエンジニアのための祭典
- 今年のテーマは「Extend Your Engineering Life!」
メモ
凡例
☆: ToDo（追加で調べておくことなど）
⚫️: 重要（転用）ポイント
Kubernetes、第一歩のその後に ~基盤を支えるOSSとの関わり方~@太田 航平 (inductor)
- チュートリアルから先に進めていない人向け
- k8sの構成
- それらがどうやって開発しているか
- DockerはdotCloud社が公開したLXCベースのアプリケーションが始まり
- k8sはインフラを抽象化。統一されたインターフェイス。「どのホストに〜」ではなく「メモリ2G欲しい」
- k8sの3つの顔⚫️
- コンテナオーケストレーション
- コンテナをデプロイ
- 分散システム
- ノードをクラスタリング
- 柔軟なジョブスケジューリング
- 分散KVSが鍵
- Platform for Platform
- コンテナオーケストレーション
- CNCF
- Linux FoundationとGoogleが設立
- Kubernetes以外にも
- コンテナ技術単体ではない
- ベンダーの偏っているプロジェクトは受け入れない
- SIGs
- あらゆる決定はSIGによって行われる
- SIGごとにチェア（代表）がいる
- api-serverの標準化
- テスト自動化の推進
- ドキュメント化
- k8sそのものがコンポーネントにわかれたマイクロサービス
- k8sの構成⚫️
- クラスター
- （補足）kube キューベ
- kube-api-server
- 全てがここを通る
- etcdに触れる唯一の存在
- kubectl
- contoroller Manager
- kube-schedurler
- cronとかとは違う
- 新しいPodが作られたときに、どこに配置するかを決定
- kubelet
- ノードに1台いて、まず、ノードがいるよ、と伝える
- 命令を受けたら、コンテナ作成司令をコンテナランタイムに送信
- kube-proxy
- 「どのノードでも同じように動いて欲しい」=「ネットワークを透過的に」
- iptables
- コンテナランタイム
- Docker以外も
- kubeletのCRI（インターフェイス）が喋れるならいける
- どこで開発されているか
- kubeで始まるものは大元のリポジトリ
- それ以外は個別のSIG（cloud contoroller managerとか）
- etcdは別
- 公式のチュートリアルがある
- 認定資格がある
- kubernetes the hard way⚫️
- k8sの基本構造はWebアプリケーションと同じ
- 自動化の恩恵をフルに活用するためには両方の知見が必要
- Don’t ask to ask
- Land Scape, Trail Map
- KEPで議論されている
- 世界で二番目に大きなコミュニティ⚫️
- Docs以外で面白そうなSIG
- kube proxyがBGP?
- CNIがBGPを使うことがある
- workerがdata planeに？名称を統一。今は動いていない。
- ☆構成全体像の図
- ☆k8s記事への反映（k8s構成の説明）
AKSを活用した内製教育支援プラットフォームをリリースした話@河原 慎吾
- 経歴
- テクノベーションセンター
* 全員が専任（他社では兼任があるある？）
- ブランド向上、全社の技術スキル向上
- 内製教育のメリット
- 実業務で発生した疑問をすぐに聞ける。いざ必要になった時に。
- 勉強会は、現場と研究組織の接点⚫️
- 講師は現場の状況を把握することができる
- 実業務で発生した疑問をすぐに聞ける。いざ必要になった時に。
- 勉強会（イベント）の当初の課題
- 申し込んだのを忘れるとか申請とか
- 開発の前にデザインシステム
- ☆表
- ペルソナ設計大事⚫️
- インタビューの分析結果から、共通点を抽出し人物像を当てていく
- カスタマージャーニーマップの作成⚫️
- プロトタイプの作成⚫️
- Prott
- モックアップの段階でユーザテスト
- デザインプロセスは時間がかかる
- ペルソナやマップをアウトプットすることで後で立ち返れることがメリット⚫️
- なぜAKS使ったか
- Web App for Containerでもよかった
- 運用してみないと、k8sの良さや苦労が分からない。⚫️
- Azure ARM Template
- コード化にこだわりすぎない。初期セットアップを楽にする、くらい⚫️
- もし壊れても一から作り直せる安心感
- パスワードは、実行するときに指定
- 公式にクイックスタートテンプレートがある⚫️
- 頻繁に変更が入るのはマニュフェストファイルの方。こっちはあんまり。
- 本番と検証でクラスタを分けている
- k8sのアップデートの検証⚫️
- ステージングは監視していない、開発環境と同居
- 結局、開発とステージングは同ノードでnamespaceを分けて構築した⚫️
- Nginx Ingress
- 社内からのみアクセスするように元IPを制御
- Let's Encrypt⚫️
- Helm Install
- Helm⚫️
- アップデート⚫️
- k8sはとにかく早い
- HPA
- Podの使用状況に応じて
- ヘルスチェック
- Podの再起動
- Podへの通信を止める
- 色々パラメータがある。ヘルスチェック開始までの時間とか
- Azure Monitorで監視
- コンテナーが落ちても自己復旧だが、クラスタ自身は監視
- Slackに通知
- -> 細かくログを見るときはkubectl logs, describe⚫️
- コンテナレジストリ
- 脆弱性スキャン⚫️
- CI/CD⚫️
- drone
- developブランチ→開発環境に
- master->ステージング環境に
- タグ→本番環境に
- secretはWebUIから事前設定
- コミットハッシュ値をタグに
- デプロイはkubectl applyとかを書いていく
- latestを使いたくない
- 動的に変更したい
- リリース後に不具合があった場合に、即座にリストアできるかどうかが大事
- CI/CDはリストア駆動で設計する。劇的に生産性が上がるため、早めに作った方が良い。⚫️
- logはAzureに転送。ESとかは使っていない。Azureのlog analitics。
人のチームでどうやって開発者をkubernetes開発に巻き込もうとしているか@大平 譲
- Terraform Cloud, argocdでGitops⚫️
- 人数が少ないチームこそ自動化
- 連絡のフローを飛ばして、開発者にマニュフェストを書いて反映をしてもらっている
- マイクロサービス
- コンテナが増えていったときにどうするか。保守作業
- -> 開発チームの一人にインフラ構築を任せた
- uberとかはmicroではなくmacroくらい
Prowに学ぶKubernetesのCI環境@bells17
- k8sリポジトリへのPRに対してbotが自動でラベル付与
- chat ops
- Githubと親和性が高い
- prow自体がk8s上で動作する
- 嬉しいこと
- ジョブの実行機能
- Issue/PRの管理。リポジトリのライフサイクル
- アーキテクチャ
- GitLabは未対応
- GitHubのbotアカウントが必要
- アクセス制限はoauth-proxyとかで⚫️
- 認証機能のないアプリケーションでOAuth2認証を提供する
- OAuth2 Proxy は、リバースプロキシサーバーのように動作
Kubernetesを用いた車両用クラスタ管理とvehicle service mesh@Yong Jun Kai / @天地 知也(tomoyamachi)
- 車向けの注意点
- linuxと限らない
- NWの切断
- Misaki
- k8sベース
- 組み込みを学ぶ必要がない
- NW瞬断問題に対応
- まだプロトタイプ
- ECU
- 仕組み
- Cloudにmasterがいて、車にnode
- VPNで接続
- 車のスペックによって載せるコンテナ（機能）は変える
- Helmでデプロイを管理
- サービスメッシュとは
- control planeとdata plane
- ローカルのDNSマスク
”ワタシハ セフ チョットデキル" への道
- Ceph
- マジイケ頭足類
- SPOFなし
- オブジェクトストレージもファイルシステムもブロックデバイスも
- NFSも
- 勝手にリバランスしたりスクラブしたり。運用負担を減らしてくれる。
- APIが色々
- 専用ハードは必要なし
- ☆かっこいい公式動画がある
- 歴史
- 2003年（S3は2006年）
- 原理的な部分は当初から洗練されている
- だいたい1年に1回のメジャーリリース
- ライフサイクルは2年
- アーキテクチャ
- CRUSHアルゴリズムとは
- CRUSH Map & Rule
- 物理配置トポロジーを定義
- フロアを分けるとかラックを分けるとか
- 物理配置を考慮してデータを配置してくれるように
- poolごとに設定。poolAはhostレベルの分散でいい、rackレベルの分散でいい、roomレベルの分散までする、など
- Placement Group
- clientは、どのPGにデータを預けるかだけ
- weightを考慮（人が計算するわけではない）
- librados
- 各種言語向け
- rados gateway
- S3互換
- RBD
- ブロックデバイス
- ファイルシステムのメタデータはMDSが管理
- NFS Exportも可能
- MDS
- CephFSのメタデータ管理のデーモン（メモリ上で管理）
- コンテナ仮してコンテナオーケストレーション基盤上で管理しやすい
- Rook
- 分散システムなので、速いネットワークは正義
ツイートしたこと
kubernetes the hard way Kubernetesクラスタを立ち上げるための必要な各タスクを確実に理解するための、長い道のり https://springmt.github.io/kubernetes-the-hard-way-ja/kubernetes_the_hard_way/#0 #JTF2020 #JTF2020D
CI/CDはリストア駆動で設計する。劇的に生産性が上がるため、早めに作った方が良い。 Droneを利用。latestタグを使わないために動的に変更するようゴニョゴニョ工夫。 #JTF2020 #JTF2020D
