- 要件
- デザインの選択
- 設定
- インストールコマンドラインオプション
- チャート構成例
- このChartのコミュニティ版を使って
- 外部サービス
- メトリクス
- チャート全体の既定値
- ポッドごとの設定
-
を設定します。
networkpolicy
GitLab-Sidekiqチャートの使い方
sidekiq
サブチャートは、Sidekiq ワーカーのコンフィギュレーション可能なデプロイを提供し、個々のスケーラビリティとコンフィギュレーションで複数のDeployment
にまたがるキューの分離を提供するように明示的に設計されています。
このChartはデフォルトのpods:
宣言を提供しますが、空の定義を提供した場合、ワーカーは存在しません。
要件
このチャートは、完全なGitLabチャートの一部として、あるいはこのチャートがデプロイされているKubernetesクラスターから到達可能な外部サービスとして提供されている、Redis、PostgreSQL、Gitalyサービスへのアクセスに依存しています。
デザインの選択
このChartでは、複数のDeployment
sと関連するConfigMap
sが ConfigMap
作成されますConfigMap
。 ConfigMap
コマンドの長さに関する懸念を避けるために、environment
属性やコンテナ用のcommand
への追加引数を使用する代わりに、ビヘイビアをConfigMap
使用する方が明確 ConfigMap
であると判断されました。この選択により、ConfigMap
sの数は多くなりますが、各ポッドが何をすべきかの定義は非常に明確になります。
設定
sidekiq
チャートは、チャート全体の外部サービス、チャート全体のデフォルト、ポッドごとの定義の3つの部分で構成されます。
インストールコマンドラインオプション
以下の表は、--set
フラグを使用して、helm install
コマンドに供給できるすべての可能なチャート設定です:
パラメータ | デフォルト | 説明 |
---|---|---|
annotations
| ポッド注釈 | |
concurrency
| 25
| Sidekiqデフォルトの同時実行性 |
cluster
| true
| 以下をご覧ください。 |
enabled
| true
| Sidekiq有効フラグ |
extraContainers
| 追加コンテナのリスト | |
extraInitContainers
| 追加するinitコンテナのリスト | |
extraVolumeMounts
| 設定する追加ボリュームマウントの文字列テンプレート | |
extraVolumes
| 設定する追加ボリュームの文字列テンプレート | |
extraEnv
| 公開する追加環境変数のリスト | |
gitaly.serviceName
| gitaly
| Gitalyサービス名 |
hpa.targetAverageValue
| 350m
| オートスケーリング目標値の設定 |
minReplicas
| 2
| 最小レプリカ数 |
maxReplicas
| 10
| レプリカの最大数 |
maxUnavailable
| 1
| 利用できないポッドの最大数の制限 |
image.pullPolicy
| Always
| Sidekiq画像プルポリシー |
image.pullSecrets
| 画像リポジトリの秘密 | |
image.repository
| registry.gitlab.com/gitlab-org/build/cng/gitlab-sidekiq-ee
| Sidekiq画像リポジトリ |
image.tag
| Sidekiq画像タグ | |
init.image.repository
| initContainer イメージ | |
init.image.tag
| initContainer画像タグ | |
logging.format
| default
| JSON構造化ログの場合、json 。
|
metrics.enabled
| true
| Prometheus メトリクス・エクスポーターの切り替え |
psql.password.key
| psql-password
| psqlシークレットのpsqlパスワードへのキー |
psql.password.secret
| gitlab-postgres
| psqlパスワード秘密 |
psql.port
| PostgreSQL サーバのポートを設定します。global.psql.port
| |
redis.serviceName
| redis
| Redisサービス名 |
resources.requests.cpu
| 100m
| Sidekiqの最小必要CPU |
resources.requests.memory
| 600M
| Sidekiq最小必要メモリ |
timeout
| 5
| Sidekiqジョブのタイムアウト |
tolerations
| []
| ポッド割り当てのためのトレラベル |
memoryKiller.daemonMode
| false
|
true がデーモンのメモリキラーモードを有効にしている場合
|
memoryKiller.maxRss
| 2000000
| 遅延シャットダウンが発生するまでの最大RSS(キロバイト単位 |
memoryKiller.graceTime
| 900
| シャットダウンがトリガーされるまでの待機時間(秒単位 |
memoryKiller.shutdownWait
| 30
| シャットダウンがトリガーされた後、既存のジョブが終了するまでの時間(秒単位 |
memoryKiller.hardLimitRss
| デーモンモードで即時シャットダウンが発生するまでの最大RSS(キロバイト単位 | |
memoryKiller.checkInterval
| 3
| デーモン・モードでのメモリ・チェック間の時間 |
livenessProbe.initialDelaySeconds
| 20 | 生存性プローブが開始されるまでの遅延 |
livenessProbe.periodSeconds
| 60 | 生存性プローブの実行頻度 |
livenessProbe.timeoutSeconds
| 30 | 生存性プローブがタイムアウトした場合 |
livenessProbe.successThreshold
| 1 | 一度失敗したプローブが成功したとみなされるための最小連続成功回数 |
livenessProbe.failureThreshold
| 3 | プローブが成功した後、失敗したとみなすための最小連続失敗数 |
readinessProbe.initialDelaySeconds
| 0 | 準備完了プローブが開始されるまでの遅延 |
readinessProbe.periodSeconds
| 10 | レディネス・プローブの実施頻度 |
readinessProbe.timeoutSeconds
| 2 | 準備完了プローブがタイムアウトした場合 |
readinessProbe.successThreshold
| 1 | レディネス・プローブが失敗した後、成功したとみなされるための最小連続成功回数 |
readinessProbe.failureThreshold
| 3 | 準備完了プローブが成功した後、失敗したとみなされるには、最低連続失敗回数が必要です。 |
securityContext.fsGroup
| 1000
| ポッドを起動するグループID |
securityContext.runAsUser
| 1000
| ポッドを起動するユーザID |
updateStrategy
| {}
| デプロイによって使用されるアップデート戦略を設定できます。 |
priorityClassName
| ""
| ポッドの設定を許可するpriorityClassName , これは、立ち退き時にポッドの優先度を制御するために使用されます。
|
チャート構成例
エクストラエンバイロメント
extraEnv
を使うと、 dependencies コンテナで追加の環境変数を公開することができます。
以下はextraEnv
の使用例です:
extraEnv:
SOME_KEY: some_value
SOME_OTHER_KEY: some_other_value
コンテナが起動したら、環境変数が公開されていることを確認できます:
env | grep SOME
SOME_KEY=some_value
SOME_OTHER_KEY=some_other_value
エクストラボリューム
extraVolumes
により、Chart 全体で追加ボリュームを設定できます。
以下はextraVolumes
の使用例です:
extraVolumes: |
- name: example-volume
persistentVolumeClaim:
claimName: example-pvc
エクストラボリュームマウント
extraVolumeMounts
を使用すると、Chart 全体ですべてのコンテナに追加の VolumeMount を設定できます。
以下はextraVolumeMounts
の使用例です:
extraVolumeMounts: |
- name: example-volume-mount
mountPath: /etc/example
画像.pullSecrets
pullSecrets
を使うと、非公開レジストリで認証してポッドのイメージを取り出せるようになります。
非公開レジストリとその認証方法についての詳細は、Kubernetesのドキュメントに記載されています。
以下はpullSecrets
の使用例です:
image:
repository: my.sidekiq.repository
pullPolicy: Always
pullSecrets:
- name: my-secret-name
- name: my-secondary-secret-name
こうわん
tolerations
汚染されたワーカーノードでポッドのスケジューリングが可能
以下はtolerations
の使用例です:
tolerations:
- key: "node_label"
operator: "Equal"
value: "true"
effect: "NoSchedule"
- key: "node_label"
operator: "Equal"
value: "true"
effect: "NoExecute"
コンメンタール
annotations
を使用すると、Sidekiqポッドに注釈を追加できます。
以下はannotations
の使用例です:
annotations:
kubernetes.io/example-annotation: annotation-value
このChartのコミュニティ版を使って
デフォルトでは、HelmチャートはGitLabのEnterprise Editionを使用します。 必要であれば、代わりにCommunity Editionを使用することもできます。両者の違いについてはこちらをご覧ください。
コミュニティ版を使用するには、image.repository
をregistry.gitlab.com/gitlab-org/build/cng/gitlab-sidekiq-ce
に設定します。
外部サービス
このチャートは、Webserviceチャートと同じRedis、PostgreSQL、Gitalyインスタンスにアタッチする必要があります。 外部サービスの値は、すべてのSidekiqポッドで共有されるConfigMap
。
Redis
redis:
host: rank-racoon-redis
port: 6379
sentinels:
- host: sentinel1.example.com
port: 26379
password:
secret: gitlab-redis
key: redis-password
名称 | タイプ | デフォルト | 説明 |
---|---|---|---|
host
| 文字列 | 使用するデータベースを持つ Redis サーバーのホスト名。serviceName の代わりに省略することもできます。 Redis Sentinels を使用する場合は、host 属性にsentinel.conf で指定したクラスター名を設定する必要があります。
| |
password.key
| 文字列 | Redisのpassword.key 属性は、パスワードを含むシークレット(下記)のキーの名前を定義します。
| |
password.secret
| 文字列 | Redisのpassword.secret 属性は、プルするKubernetesSecret の名前を定義します。
| |
port
| 整数 | 6379
| Redisサーバーに接続するポート。 |
serviceName
| 文字列 | redis
| Redis データベースを運用しているservice の名前。これが存在し、host が存在しない場合、Chart はhost の値の代わりにサービスのホスト名(および現在の.Release.Name )をテンプレート化します。これは、Redis を GitLab チャート全体の一部として使用する場合に便利です。
|
sentinels.[].host
| 文字列 | Redis HAセットアップのRedis Sentinelサーバのホスト名。 | |
sentinels.[].port
| 整数 | 26379
| Redis Sentinelサーバーに接続するポート。 |
_注意:_現在のRedis Sentinelサポートは、GitLabチャートとは別にデプロイされたSentinelのみをサポートしています。 そのため、GitLabチャートを介したRedisのデプロイは、redis.install=false
。 Redisのパスワードを含むシークレットは、GitLabチャートをデプロイする前に手動で作成する必要があります。
PostgreSQL
psql:
host: rank-racoon-psql
serviceName: pgbouncer
port: 5432
database: gitlabhq_production
username: gitlab
preparedStatements: false
password:
secret: gitlab-postgres
key: psql-password
名称 | タイプ | デフォルト | 説明 |
---|---|---|---|
host
| 文字列 | 使用するデータベースがある PostgreSQL サーバのホスト名です。postgresql.install=true の場合は省略可能です(デフォルトは non-production)。
| |
serviceName
| 文字列 | PostgreSQLデータベースをオペレーションしているservice の名前です。これが存在し、かつhost 存在しない場合、Chartは host 値のhost 代わりにサービスのホスト名をテンプレート化 host します。
| |
database
| 文字列 | gitlabhq_production
| PostgreSQL サーバで使用するデータベース名。 |
password.key
| 文字列 | PostgreSQLのpassword.key 属性は、パスワードを含むsecret(以下)のキーの名前を定義します。
| |
password.secret
| 文字列 | PostgreSQLのpassword.secret 属性は、プルするKubernetesSecret の名前を定義します。
| |
port
| 整数 | 5432
| PostgreSQLサーバに接続するポート。 |
username
| 文字列 | gitlab
| データベースを認証するためのユーザ名。 |
preparedStatements
| ブール | false
| PostgreSQLサーバと通信する際に準備された文を使用する場合。 |
Gitaly
gitaly:
internal:
names:
- default
- default2
external:
- name: node1
hostname: node1.example.com
port: 8079
authToken:
secret: gitaly-secret
key: token
名称 | タイプ | デフォルト | 説明 |
---|---|---|---|
host
| 文字列 | 使用するGitalyサーバーのホスト名。serviceName の代わりに省略することもできます。
| |
serviceName
| 文字列 | gitaly
| Gitalyサーバーをオペレーションしているservice の名前。これが存在し、host が存在しない場合、Chartはhost の値の代わりにサービスのホスト名(と現在の.Release.Name )をテンプレートします。これはGitalyをGitLabチャート全体の一部として使用する場合に便利です。
|
port
| 整数 | 8075
| Gitalyサーバーに接続するポートです。 |
authToken.key
| 文字列 | authToken を含む以下の秘密のキーの名前。 | |
authToken.secret
| 文字列 | プルするKubernetesSecret の名前。
|
メトリクス
デフォルトでは、Prometheusメトリクスエクスポーターがポッドごとに有効になっています。 メトリクスは、管理エリアでGitLab Prometheusメトリクスが有効になっている場合にのみ利用可能です。 エクスポーターは、ポート3807
の/metrics
エンドポイントを公開します。 メトリクスが有効になっている場合、Prometheusサーバーが公開されたメトリクスを検出してスクレイピングできるように、各ポッドにアノテーションが追加されます。
チャート全体の既定値
以下の値は、ポッド単位で表示されないイベントにおいて、チャート全体で使用されます。
名称 | タイプ | デフォルト | 説明 |
---|---|---|---|
concurrency
| 整数 | 25
| 同時に処理するタスクの数。 |
cluster
| ブール | true
| ポッドごとの値で上書きされます。 |
timeout
| 整数 | 4
| Sidekiqのシャットダウンタイムアウト。 SidekiqがTERMシグナルを受け取ってから、プロセスを強制的にシャットダウンするまでの秒数。 |
memoryKiller.maxRss
| 整数 | 2000000
| 遅延シャットダウンが発生するまでの最大RSS(キロバイト単位 |
memoryKiller.graceTime
| 整数 | 900
| シャットダウンがトリガーされるまでの待機時間(秒単位 |
memoryKiller.shutdownWait
| 整数 | 30
| シャットダウンがトリガーされた後、既存のジョブが終了するまでの時間(秒単位 |
minReplicas
| 整数 | 2
| 最小レプリカ数 |
maxReplicas
| 整数 | 10
| レプリカの最大数 |
maxUnavailable
| 整数 | 1
| 利用できないポッドの最大数の制限 |
ポッドごとの設定
pods
宣言は、ワーカーポッドのすべての属性の宣言を提供します。これらは、Deployment
s にテンプレート化され、Sidekiq インスタンスには個別のConfigMap
s があります。
名称 | タイプ | デフォルト | 説明 |
---|---|---|---|
concurrency
| 整数 | 同時に処理するタスクの数。 指定がない場合は、チャート全体のデフォルト値から引かれます。 | |
cluster
| ブール | true
| 以下をご覧ください。 |
name
| 文字列 | このポッドのDeployment とConfigMap の名前に使用します。 短く、2 つのエントリ間で重複しないようにします。
| |
queues
| 文字列 / 配列 | 以下をご覧ください。 | |
negateQueues
| 文字列 / 配列 | 以下をご覧ください。 | |
experimentalQueueSelector
| ブール | false
|
実験的キューセレクタを使用。cluster が有効な場合のみ有効。
|
timeout
| 整数 | Sidekiqのシャットダウンタイムアウト。 SidekiqがTERMシグナルを取得した後、プロセスを強制的にシャットダウンするまでの秒数です。 指定されていない場合、チャート全体のデフォルトが使用されます。 | |
resources
| 各ポッドは独自のresources 要件を提示することができ、それが存在する場合は、そのために作成されたDeployment に追加されます。 これらはKubernetesのドキュメントと一致しています。
| ||
nodeSelector
| 各ポッドは、nodeSelector 属性を設定できます。この属性は、そのポッド用に作成されたDeployment に追加されます(存在する場合)。これらの定義は、Kubernetes のドキュメントと一致しています。
| ||
minReplicas
| 整数 | 2
| 最小レプリカ数 |
maxReplicas
| 整数 | 10
| レプリカの最大数 |
maxUnavailable
| 整数 | 1
| 利用できないポッドの最大数の制限 |
updateStrategy
| {}
| デプロイによって使用されるアップデート戦略を設定できます。 | |
extraVolumes
| 文字列 | 指定されたポッドの追加ボリュームを設定します。 | |
extraVolumeMounts
| 文字列 | 指定されたポッドの追加ボリュームマウントを設定します。 | |
priorityClassName
| 文字列 | ""
| ポッドの設定を許可するpriorityClassName , これは、立ち退き時にポッドの優先度を制御するために使用されます。
|
hpa.targetAverageValue
| 文字列 | 与えられたポッドのオートスケーリングターゲット値を上書きします。 |
キュー
queues
の値は、処理されるキューのコンマ区切りのリストを含む文字列です。 デフォルトでは、これは設定されておらず、すべてのキューが処理されることを意味します。
文字列にはスペースを含んではいけません。merge,post_receive,process_commit
は機能しますが、merge, post_receive, process_commit
は機能しません。
ジョブが追加されたものの、少なくとも一つのポッドアイテムの一部として表現されていないキューは処理されません。 すべてのキューの完全なリストについては、GitLabソースのこれらのファイルを参照してください:
cluster
がfalse
の場合、これはキュー名を文字列で表した配列でなければなりません。ネゲートキュー
negateQueues
はqueues
と同じ形式ですが、処理されるのではなく、無視されるキューを表します。
文字列にはスペースを含んではいけません。merge,post_receive,process_commit
は機能しますが、merge, post_receive, process_commit
は機能しません。
これは、重要なキューを処理するポッドと、それ以外のキューを処理する別のポッドがある場合に便利です。これらのポッドは、同じキューのリストを使用し、一方をqueues
に、もう一方をnegateQueues
に置くことができます。
negateQueues
は、queues
と一緒に提供negateQueues
すべきではありませんnegateQueues
。クラスター
cluster
は、Sidekiqプロセスを開始するためにSidekiq Clusterを使用することを示します。 ブーリアン以外が指定された場合、その値は無視されます。
現在のデフォルトはtrue
です。
Sidekiq Clusterを使用する場合、queues
(またはnegateQueues
)は文字列でなければなりません。Sidekiq Clusterを使用しない場合、文字列の配列でなければなりません。後者のオプションはGitLab 14.0からはサポートされません。
cluster
、1つのポッド内部で複数のSidekiqプロセスが起動することはありません。追加のSidekiqプロセスを実行するには、追加のポッドを実行してください。
pod
記入例
pods:
- name: immediate
concurrency: 10
minReplicas: 2 # defaults to inherited value
maxReplicas: 10 # defaults to inherited value
maxUnavailable: 5 # defaults to inherited value
queues:
- [post_receive, 5]
- [merge, 5]
- [update_merge_requests, 3]
- [process_commit, 3]
- [new_note, 2]
- [new_issue, 2]
extraVolumeMounts: |
- name: example-volume-mount
mountPath: /etc/example
extraVolumes: |
- name: example-volume
persistentVolumeClaim:
claimName: example-pvc
resources:
limits:
cpu: 800m
memory: 2Gi
hpa:
targetAverageValue: 350m
を設定します。networkpolicy
このセクションはNetworkPolicyを制御します。 この設定はオプションで、ポッドの Egress および Ingress を特定のエンドポイントに制限するために使用します。
名称 | タイプ | デフォルト | 説明 |
---|---|---|---|
enabled
| ブーリアン | false
| この設定により、ネットワークポリシ |
ingress.enabled
| ブーリアン | false
|
true に設定すると、Ingress ネットワークポリシーが有効になります。ルールが指定されていない限り、すべての Ingress 接続がブロックされます。
|
ingress.rules
| 配列 | []
| 詳細はhttps://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource と以下の例を参照してください。 |
egress.enabled
| ブーリアン | false
|
true に設定すると、Egress ネットワークポリシーが有効になります。ルールが指定されていない限り、すべてのイグレス接続がブロックされます。
|
egress.rules
| 配列 | []
| 詳細はhttps://kubernetes.io/docs/concepts/services-networking/network-policies/#the-networkpolicy-resource と以下の例を参照してください。 |
ネットワークポリシー例
Sidekiqサービスは、有効な場合はPrometheus exporterのみにIngress接続を必要とし、通常は様々な場所にEgress接続を必要とします。 この例では、以下のネットワークポリシーを追加します:
- TCP
10.0.0.0/8
ポート 3807 のネットワークからのすべての Ingress 要求は、メトリクスのエクスポー トで許可されます。 - UDP
10.0.0.0/8
ポート53のネットワークへのすべてのEgressリクエストは、DNSのために許可されています。 - TCP
10.0.0.0/8
ポート 5432 のネットワークへのすべての Egress リクエストは PostgreSQL に対して許可されます。 - TCP
10.0.0.0/8
ポート 6379 のネットワークへのすべての Egress リクエストは、Redis に対して許可されています。 -
10.0.0.0/8
、内部ネットワークへのその他のEgressリクエストは制限されています。 -
10.0.0.0/8
、内部からの退出要求が許可されます。
例題はあくまで一例であり、完全なものではありません。
Sidekiqサービスでは、外部オブジェクトストレージ上の画像を公開インターネットに接続する必要があります。
networkpolicy:
enabled: true
ingress:
enabled: true
rules:
- from:
- ipBlock:
cidr: 10.0.0.0/8
ports:
- port: 3807
egress:
enabled: true
rules:
- to:
- ipBlock:
cidr: 10.0.0.0/8
ports:
- port: 53
protocol: UDP
- to:
- ipBlock:
cidr: 10.0.0.0/8
ports:
- port: 5432
protocol: TCP
- to:
- ipBlock:
cidr: 10.0.0.0/8
ports:
- port: 6379
protocol: TCP
- to:
- ipBlock:
cidr: 0.0.0.0/0
except:
- 10.0.0.0/8