aretan.jp

https://hbstudy.connpass.com/event/69749/

OpenShift レッドハット株式会社 木村

レッドハットではエンタープライズとは200人を3-6ヶ月で作ったものを指す
カスタマーソースデフィにション
うっかりディスクフル確定の大容量イメージをデプロイしたらどうなるの？
プロダクションのためにはHA構成 マスター追加削除 ノード追加削除 etcd追加削除 アップグレードが必要
学習目的のチュートリアルから本番運用すると死ぬ
バックアップリストア検証はしっかりしよう
何台までなら死んでいいかはちゃんと計算しておく
マスターやetcdはノード100までなら16ギガ、それ以上なら32ギガ
マスターはメモリ50%以上空かせておく
etcdは2メンバーだと片方落ちたら機能しない、3から奇数で増やす必要
マルチazするにも、少なくとも3つのazが必要
メンバー間ネットワークレイテンシ2ms以下推奨
セキュリティアップデートのポリシー構築
コンテナスキャンソフトウェアなどの導入
アプリチームじゃないとリビルドできないとかはなしで
コンテナホストはポッドを逃がしてからアップデート
cpuを全て消費するようなアプリがデプロイされてノード障害にならないように必要なものは予約する
スワップがあると意図しないパフォーマンスダウン、スワップは無効にする
大きいイメージ対策はレジストリ側でどうにかがんばる
ネームスペースは分けないと辛い
オートスケールやローリングアップデートの余地を残す必要がある
cpuのrequestsのminとmaxは設定、limitsはなくてもいい
これでバースダブルになってあいてるcpuはどんどん使っていいように。
memoryはlimitsを設定、確保できないと大変なので
オートスケールは直近1分の平均で判定
ターゲットから10%幅
アップ3分 ダウン5分のコールドがある
ポッドにアノテーションでネットワーク制限
メモリやディスク不足時にpodをevictionする
pod移動のためにpod disruption budgetを設定
livenessProvbe readinessProbe terminatiomGracePeriodSecondsなどはきちんと指定しておく
他のポットやサービスを必要とする依存のチェックはprobeに
スケールダウンは実はスケジューラの条件を見ない、偏ることがある。
mysqlはいいけどnfsは絶対に使うな、fsync fdatasyncを使うようなのがだめ
readwriteonceなpv単一ノードからしかマウントできない スケール不要なアプリなど
フェイルオーバーはできる
PVはリサイズできないので多めに、そのうち使えるようになる
javaはコンテナのホストのcpuを見ていい感じにするから危険 メモリもそう
無設定ならgcが大量に割り当ててアプリが動かない
goなど各種ライブラリも自動チューニングがあったら注意

2azしかない場合どうする→そもそもマルチazはオススメできない クラスターフェデレーション待ち
NFSはHA構成とかしにくいし壊れやすいし障害になりやすいからやめとこ
どのポッドにもフルーエンとおるで問題→ログは標準出力してくれという建前
HAproxyとかsyslogしか対応してない男らしいのは大変
kubernatesはL3のLBだから結局はL7はHAProxy使ってる
ラベルでノードセレクターで構成する 商用のcniプラグイン
ネットワーク的に分断したい時は、ノード限定、ソースip限定とかはクラウドとは合わない
このノード結局オンプレじゃんみたいなことはある イングレスルーターで送信したり
お客さんでプロキシ建ててどうにかして
ビルドもクラスタに投げてやると便利だよ
クラウドネイティブなデータストア使う、mysql普通に建てていんじゃないの
パイオニア ソフバン necとかが使ってる