Amazon EKS によるスマホゲームのバックエンド運用事例
- AWSのEC2上でPodが起動する際、EC2には2つのENIが付与される。ENIにはIPアドレスが事前に確保されプールされる。（インスタンスサイズによって異なりc5.largeでは20個/ENIのため40IPが確保される）
- そのためEC2を多数起動すると払い出せるIPアドレスがなくなりIPがアサインできなくなった
- 対応策としてはサブネットのレンジを広めにしておくこと
- VPC CNIプラグインの
WARM_IP_TARGET設定をいじり確保する見アサインのIPアドレス数をへらす など
- k8sのアップデートの問題
- VPCにk8sクラスタを２つつくりドメインレベルで切り返す
- ステートフルなデータはクラスタ外へだす
- アップデートが多いので事前にどのように更新するかは考えておくこと
- ローリングアップデートでbad gatewayが発生
- AWS Ingressのターゲットグループの宛先はNodePort宛てとPod宛てが選べる。今回はPod宛てにした（Pod宛てだと1Hopで通信できるので）
- この時、Ingressからの振り分け先からの削除とPodの終了が非同期で行われたため、終了したPodに通信が行われBad Gatewayが発生した
- 対応策としてPodの終了時にSleepを挟んでターゲットグループから登録削除される十分な時間待機するようにした
- しかしPodの数が増えるとALBが発行するAPIの数が増え過ぎてスロットリング（リクエストを送信できる頻度を制限する. ）が発生し、IngressがターゲットグループからPodを削除する秒数がSleep以上になりまたBadGatewayが再発した
- 対策としてAPIコールのリトライを減らすこととした。また一般的にはpreStopフックでヘルスチェックを失敗させるなど。
Kubernetes Security for Microservices
- メルカリではkubernetesをシングルクラスタで運用しており、NameSpaceで分割している。
- kubernetesではデフォルトではセキュアでない点がある。
- 外部からの攻撃と内部からの攻撃を想定
- 外部 RBACとPodSecurityPolicy（Gatekeeper）を使って高権限のPod作成を防いでいる
- 内部 SSRFによるインスタンスメタデータの取得を防ぐためにGKEの場合はWorkload Identityで防いでいる
- Network Policy
- PodSecurityPolicy
- conftestとルールを組み合わせてCICDで
- Falco/Sysdig Secureで不正検知
- Mutual TLS with Istio（Mutual Authentication) 検討中
- gVisor 検討中
