my cognition

Cognitiveはよいぞ。電波伝搬はよいぞ。

#ふくばねてす node-1 にお邪魔してきました。

まとめ（個人、運営問わず）

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)

cgroup v2とPSIがサポートされ、今までホストごとだったパフォーマンス情報取得がコンテナ単位になり、今後のCloud Nativeで利用されるかもしれないという話。

何と読む？謎のk3s by Shindo Yosukeさん (@sindoy)

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レイヤー
    • RBACを有効に、最低限--anonymous-auth falseに。
    • コンポーネント間TLS通信を有効に
    • 保管しているデータの暗号化
    • K8s監査ログの有効化
    • システムデーモン用コンピューターリソースの予約
    • Admission Controllers
  • 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は消化不良なので、別途まとめたい。