はじめに
前回の記事の続きの記事になります
マニフェストファイル
リソース
18までは前回記事をご覧ください
19. Service Account
k8sにおいて、Podが擬似的にユーザーとして振る舞うためのリソース。
bot用のアカウントを作るイメージ。
人間ではなく、Podが外部サービス(k8s以外のサービス)にアクセスするためのアカウントをこのリソースで作ることができる。
例えば、APIとかAWSのS3とかにアクセスするためのアカウントを作ることができる。
特に、EKSにおいては、Service Accountを作ることで、PodがAWSのサービスにアクセスするためのIAMロールを紐付けることができる。
そもそも、Pod絶対にService Accountに紐づいており、
何も指定しないと、defaultという名前のデフォルトのService Accountが紐づくようになっている
拡張機能(CRD(Custom Resource Definition))
kubernetesはCRDという拡張機能を使うことで、k8sのリソースを拡張することができる。
Knative
k8s上でサーバーレス風のアプリケーションを構築するためのフレームワーク。
Google、Pivotal、IBM、Red Hatなどが共同で開発を行なったツール。
HPAだとCPU使用率をベースにPodの数を増減させるが、Node.jsはマルチスレッドではなく、シングルスレッドのイベントループで動作しているため、CPUの使用率が急増したり急減したりすることがあり、HPAのスケーリングのトリガーとしては不向き。
その弱点を補うために、Knativeでは、リクエスト数をベースにPodの数を増減させることができる。
0台からスケールアップすることができ、常にアクセスがあるわけではないアプリケーションにも向いている。 (ただし0台からスケールアップする場合、初回アクセス時にCold Startが発生するため、初回アクセス時のレスポンスが遅くなる)
参考
- https://qiita.com/knqyf263/items/ecc799650fe247dce9c5
- https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/associate-service-account-role.html
- https://qiita.com/hsmto25519/items/9ac6e77d699beca6ddc5
- https://knative.dev/
- https://www.redhat.com/ja/topics/microservices/what-is-knative
- https://qiita.com/kokohei39/items/7e28f4ffd07d5245d5ac