まとめ(個人、運営問わず)
Toggeter: https://togetter.com/li/1336069
loftkun: https://github.com/loftkun/conference/blob/master/2019/0408-fukubernetes-01/README.md
セッション
本当の"""負荷検知"""をお見せしますよ - cgroup v2 feat. PSI by Uchio Kondoさん (@udzura)
- 資料: https://speakerdeck.com/udzura/cgroup-v2-and-psi
- 参照:
cgroup v2とPSIがサポートされ、今までホストごとだったパフォーマンス情報取得がコンテナ単位になり、今後のCloud Nativeで利用されるかもしれないという話。
何と読む?謎のk3s by Shindo Yosukeさん (@sindoy)
- 資料: TBO
- 参照:
Rancherの中の人。かなり駆け足だったけど、とにかく話が面白かった。紹介されていた資料が私のような初学者にとってはとても参考になった。
RancherとRancherOSについては、個人的に非常に便利。
kokotapでPodのパケットキャプチャ by Takayuki Konishiさん (@leather_sole)
Kubernetesのpodにパケットキャプチャ用のmirrorデバイスが作成できるという話。Nodeから出る前の生のパケットを拾えるので、これは楽しそう。ネットワーク系のセッションにも使えそうで後ほど試したい。
telepresenceにキャッチアップ - 後藤さんを倒すには - (仮題) by kunitさん (@kunit)
telepresenceはKubernetesの一部のpodをローカルのサーバやDockerに置き換えることができるという話。何が幸せかというと、ビルド毎のpod更新の手間なんかを省くことができる。
いっぱい kustomize する by iwaさん (@mananyuki)
- 資料: TBO
kubectlにapplyするYAMLをレイヤー管理できるようにするツール。YAML同士でinclude、overrideできるようになるイメージ。
似たようなツールとしてHelmがあるが、kustomizeでは生のYAMLを編集し、レイヤーを重ねるイメージなのに対し、Helmの場合はカタログが用意されるが、$変数
のようなテンプレートを提供するため、テンプレートを元新しいYAMLを生成するイメージ。
Secure your K8s cluster from multi-layers by Transnanoさん (@transnano)
YahooでK8sを実運用した際のノウハウ。元のスライドは30分だったが5分でザッと読むLT。その場でざっくり読んで何となくそうだろうなーぐらいしかわからなったので、後ほど読んだ試訳を置いておきます。
Secure your K8s cluster from multi-layers 試訳
- 何故Kubernetesはセキュリティを困難にするのか
- Infrastructureレイヤー
- 監査ログ(audit log)の有効化
- 不要なポートをEXPOSEしない
- 可能であればクラスタをプライベートサブネットかVPC内でホストする
- KubernetesノードへのSSHを制限し、”kubectl”を使用する
- kube-apiへのアクセスを制限する
- K8s Control Planeレイヤー
- Admission Controllers
- Kubernetes API サーバ内のフラグ設定によって有効に
- Admissino Controllersを “validating”,”mutating”,もしくは両方に
- K8s Workloadレイヤー
- ルートユーザー以外でのコンテナ実行
- クラスター単位でのポッドセキュリティポリシーの実行
- クラスタネットワークポリシーの作成と定義
- 名前空間による孤立化
- ポッドがアクセスできるノードの制御
- リソース割り当て設定による機能制限
- セキュリティコンテキスト
- K8s Container Runtimeレイヤー
- Kata ContainerはLightweight VMでKernelが独立している
- その分パフォーマンスは低い
- User Misconfigurationレイヤー
- 最近の調査で70-75%の記号は最低でも1つの深刻なセキュリティ設定ミスを行っている
- 不要なデフォルト設定を指定しない
- シンプル、最小限の設定がエラーを少なくする
- よりよい改善のため、Annotatinoにオブジェクトの説明を付け加える
- 最新のAPIバージョンを指定する
- CI/CDパイプライン設定の確認
- https://kubesec.io/
Enjoying k8s clusuer with Minikube and Helm by loftkunさん (@loftkun)
minikubeを使った開発環境の紹介とHelm chartに自作アプリケーションを載せた話。
後ほどRancherでHelm遊んでみたところ、何となく何をするものなのかわかった。
Falcoを触ってみた by toenobuさん (@toenobu)
- 資料: TBO
https://falco.org/ CNCF謹製のセキュリティツール。K8sの侵入・異常検知のためのOSS PJ(認識間違ってたらごめんなさい)。
今回はデモとして、1. docker exec -itした際の標準出力
と2. delete podした際の障害通知
をメッセージアプリにjsonで通知するというもの。死活監視だけでも使えるので、まずはそこから導入するのもあり。
buildpack、そう、そういうことなんだ俺たちのこれからは by P山さん (@pyama86)
P山さんのいつも通りのタイトル。Cloud Nativeはモテる、婚活であるとの持論を展開しつつ、本編のBuildpacksへ。
Herokuで採用されている「プログラムのコードを解析して、必要なプラットフォームを用意し、実行可能なコンテナを作成してくれるツール」をCNCF下でOSS化したもの。
例えばphpの場合。ベースをubuntu:latest
として、nginxとphp、php-fpm、mysqlをインストールし、/var/www/
等にプログラムを配置すれば実行ができると予想されるわけだ。
それらの実行環境をDockerで実現しようとする場合、それらのコンテナの配置、関係をDockerfileやdocker-compose.ymlに記述し、CI/CDパイプラインに載せてビルドするわけだが、Buildpacksは、リポジトリ直下でpack build myapp
とするだけでmyapp
というコンテナを用意してくれる。
この思想に従えば、アプリケーションコードを書く以外は全てをBuildpacksが賄ってくれるわけだ。これは、インフラ整備の大幅なコストを解決する。依存関係を整理されたアプリケーション実行基盤はビルド毎に最新に置き換えられるわけで、脆弱性対応なども意識しなくてよくなり、スケールメリットも大きい。つまり、インフラエンジニアが設計する大部分を自動化しようという話だと解釈した。
終わりに
手書きのメモについては、以下のフォトライフに上げています。
http://f.hatena.ne.jp/kitkatayama/20180408_fukubanetesu/
その後
触発されて以下2件のブログを書きました。
minikubeとkokotapは消化不良なので、別途まとめたい。