3.4. 自動スケーリングの設定


Red Hat OpenShift Dev Spaces の自動スケーリングのさまざまな側面を説明します。

3.4.1. Red Hat OpenShift Dev Spaces コンテナーのレプリカ数の設定

Kubernetes HorizontalPodAutoscaler (HPA) を使用して OpenShift Dev Spaces オペランドのレプリカの数を設定するには、デプロイメント用の HPA リソースを定義します。HPA は指定されたメトリクスに基づいてレプリカの数を動的に調整します。

手順

  1. ターゲットメトリクスと必要なレプリカ数を指定して、デプロイメント用の HPA リソースを作成します。

    apiVersion: autoscaling/v2
    kind: HorizontalPodAutoscaler
    metadata:
      name: scaler
      namespace: openshift-devspaces
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: <deployment_name> 1
      ...
    1
    <deployment_name> には、以下のデプロイメントのいずれかに対応します。
    • devspaces
    • che-gateway
    • devspaces-dashboard
    • plugin-registry
    • devfile-registry

例3.14 devspaces デプロイメント用の HorizontalPodAutoscaler を作成する

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: devspaces-scaler
  namespace: openshift-devspaces
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: devspaces
  minReplicas: 2
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 75

この例では、HPA は devspaces という名前のデプロイメントをターゲットにしており、レプリカは最小 2 つ、最大 5 つで、CPU 使用率に基づいてスケーリングされます。

3.4.2. マシンの自動スケーリングの設定

リソースのニーズに応じてノードの数を調整するようにクラスターを設定した場合は、OpenShift Dev Spaces ワークスペースのシームレスな操作を維持するために追加の設定が必要です。

Autoscaler がノードを追加および削除する場合、ワークスペースには特別な考慮が必要です。

autoscaler によって新しいノードが追加されている場合、ノードのプロビジョニングが完了するまで、ワークスペースの起動に通常よりも時間がかかることがあります。

逆に、ノードが削除される場合、ワークスペースの使用中に中断が発生し、保存されていないデータが失われる可能性を回避するために、ワークスペース Pod を実行しているノードは Autoscaler によって削除されないことが理想的です。

3.4.2.1. Autoscaler が新しいノードを追加する場合

新しいノードが追加されている間にワークスペースが適切に起動するようにするには、OpenShift Dev Spaces インストールに追加の設定を行う必要があります。

手順

  1. CheCluster カスタムリソースで、spec.devEnvironments.startTimeoutSeconds フィールドを少なくとも 600 秒に設定して、ワークスペースの起動時に必要に応じて新しいノードをプロビジョニングするための時間を確保します。

    spec:
      devEnvironments:
        startTimeoutSeconds: 600
  2. openshift-devspaces namespace の DevWorkspaceOperatorConfig カスタムリソースで、FailedScheduling イベントを config.workpsace.ignoredUnrecoverableEvents フィールドに追加します。これにより、十分なノードが利用できない場合でもワークスペースの起動が失敗しなくなります。新しいノードがプロビジョニングされると、ワークスペースの起動を続行できるようになります。

    config:
      workspace:
        ignoredUnrecoverableEvents:
        - FailedScheduling

3.4.2.2. Autoscaler がノードを削除する場合

Autoscaler がノードを削除する必要がある場合にワークスペース Pod が削除されないようにするには、すべてのワークスペース Pod に "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" アノテーションを追加します。

手順

  1. CheCluster カスタムリソースで、cluster-autoscaler.kubernetes.io/safe-to-evict: "false" アノテーションを spec.devEnvironments.workspacesPodAnnotations フィールドに追加します。

    spec:
      devEnvironments:
        workspacesPodAnnotations:
          cluster-autoscaler.kubernetes.io/safe-to-evict: "false"

検証手順

  1. ワークスペースを起動し、ワークスペース Pod に cluster-autoscaler.kubernetes.io/safe-to-evict: "false" アノテーションが含まれていることを確認します。

    $ oc get pod <workspace_pod_name> -o jsonpath='{.metadata.annotations.cluster-autoscaler\.kubernetes\.io/safe-to-evict}'
    false
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.