内部利用などのユースケースではあまり問題にはなりませんが、OpenShiftを外部のユーザに利用させたりする場合はうっかり手がすべってビットコインを掘ったりする人が居るかもしれないのでそこそこにリソースを制限しないとなりません。
OpenShiftではユーザ毎のプロジェクト数はmaster-config.yamlのProjectRequestLimitで制限できます。
プロビジョニングされるプロジェクトの各種制限は、プロジェクトのテンプレートに設定します。
プロジェクトのデフォルトのテンプレートは以下のコマンドでファイル化できます。これを編集して制限を記述していきます。
oadm create-bootstrap-project-template -o yaml > project-request-template.yaml
制限には二つあり、LimitRangeという各Pod/Containerに割り当てることのできるリソースの制限と、Quotaというプロジェクト内のリソースの総数、もしくは個々のリソースを加算した全体に制限をかけるものがあります。
- https://docs.openshift.com/container-platform/3.3/admin_guide/limits.html
- https://docs.openshift.com/container-platform/3.3/admin_guide/quota.html
例えば自分が会社で運用していて他の人に使っていいよ、って置いてあるOpenShiftのクラスタでは、Quotaは内部利用なので特に設定していませんが、Java系のコンテナはlimitsが無い場合のデフォルトが-Xmx1303mとかになっていて1.5GBのメモリを無駄に確保してしまう関係上LimitRangeは設定しています。
以下の設定をプロジェクトテンプレートに追記することで、デフォルトで作成されるコンテナには128MBのメモリ、100m (1秒間あたり1CPUを占有した場合を1000ミリコアとしたときの100ミリコア)のCPUを最低で確保できるようにしています。コンテナはホストのリソースがある場合、512MBのメモリと4000ミリコア=4CPUまでの利用を許可しています。リソースはユーザが各デプロイの設定でこれらの範囲内であれば自由に設定できます。つまり、最初から4CPU 512MBを確保できるようにしてデプロイすることができます。それを超えるようなものをデプロイする場合(運用環境なのでリソース多めでお願いします、的なユースケース)はOpenShiftのcluster-admin権限でリソース制限を書き換える、というような流れになります。
- apiVersion: v1 groupNames: null kind: LimitRange metadata: creationTimestamp: null name: default namespace: ${PROJECT_NAME} spec: limits: - type: "Pod" max: cpu: "4" memory: "512Mi" min: cpu: "100m" memory: "128Mi" - type: "Container" max: cpu: "4" memory: "512Mi" min: cpu: "100m" memory: "128Mi" default: cpu: "4" memory: "512Mi" defaultRequest: cpu: "100m" memory: "128Mi"
あとは高負荷が予想されるクラスタでは、コンテナにリソースを持って行かれてKubeletなどが満足に動作できない、というような状況を回避するためにシステム用にメモリをCPUを事前に予約しておくという機能があるので、本番運用ではこれらも設定しておく必要があります。
https://docs.openshift.com/container-platform/3.3/admin_guide/allocating_node_resources.html
このような設定をすることで安心してビットコインを掘ることができます。