6.3. リソースのインフラストラクチャー MachineSet への移行

手順

1. ルーター Operator の IngressController カスタムリソースを表示します。

   $ oc get ingresscontroller default -n openshift-ingress-operator -o yaml

   コマンド出力は以下のテキストのようになります。

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     creationTimestamp: 2019-04-18T12:35:39Z
     finalizers:
     - ingresscontroller.operator.openshift.io/finalizer-ingresscontroller
     generation: 1
     name: default
     namespace: openshift-ingress-operator
     resourceVersion: "11341"
     selfLink: /apis/operator.openshift.io/v1/namespaces/openshift-ingress-operator/ingresscontrollers/default
     uid: 79509e05-61d6-11e9-bc55-02ce4781844a
   spec: {}
   status:
     availableReplicas: 2
     conditions:
     - lastTransitionTime: 2019-04-18T12:36:15Z
       status: "True"
       type: Available
     domain: apps.<cluster>.example.com
     endpointPublishingStrategy:
       type: LoadBalancerService
     selector: ingresscontroller.operator.openshift.io/deployment-ingresscontroller=default

2. ingresscontroller リソースを編集し、 nodeSelector を infra ラベルを使用するように変更します。

   $ oc edit ingresscontroller default -n openshift-ingress-operator -o yaml

   以下に示すように、infra ラベルを参照する nodeSelector スタンザを spec セクションに追加します。

     spec:
       nodePlacement:
         nodeSelector:
           matchLabels:
             node-role.kubernetes.io/infra: ""

3. ルーター Pod が infra ノードで実行されていることを確認します。

   1. ルーター Pod の一覧を表示し、実行中の Pod のノード名をメモします。

      $ oc get pod -n openshift-ingress -o wide
      
      NAME                              READY     STATUS        RESTARTS   AGE       IP           NODE                           NOMINATED NODE   READINESS GATES
      router-default-86798b4b5d-bdlvd   1/1      Running       0          28s       10.130.2.4   ip-10-0-217-226.ec2.internal   <none>           <none>
      router-default-955d875f4-255g8    0/1      Terminating   0          19h       10.129.2.4   ip-10-0-148-172.ec2.internal   <none>           <none>

      この例では、実行中の Pod は ip-10-0-217-226.ec2.internal ノードにあります。

   2. 実行中の Pod のノードのステータスを表示します。

      $ oc get node <node_name> 1
      
      NAME                           STATUS    ROLES          AGE       VERSION
      ip-10-0-217-226.ec2.internal   Ready     infra,worker   17h       v1.14.6+c4799753c

      1

      Pod の一覧より取得した <node_name> を指定します。

      ロールの一覧に infra が含まれているため、Pod は正しいノードで実行されます。

手順

1. config/instance オブジェクトを表示します。

   $ oc get config/cluster -o yaml

   出力は以下のテキストのようになります。

   apiVersion: imageregistry.operator.openshift.io/v1
   kind: Config
   metadata:
     creationTimestamp: 2019-02-05T13:52:05Z
     finalizers:
     - imageregistry.operator.openshift.io/finalizer
     generation: 1
     name: cluster
     resourceVersion: "56174"
     selfLink: /apis/imageregistry.operator.openshift.io/v1/configs/cluster
     uid: 36fd3724-294d-11e9-a524-12ffeee2931b
   spec:
     httpSecret: d9a012ccd117b1e6616ceccb2c3bb66a5fed1b5e481623
     logging: 2
     managementState: Managed
     proxy: {}
     replicas: 1
     requests:
       read: {}
       write: {}
     storage:
       s3:
         bucket: image-registry-us-east-1-c92e88cad85b48ec8b312344dff03c82-392c
         region: us-east-1
   status:
   ...

2. config/instance オブジェクトを編集します。

   $ oc edit config/cluster

3. テキストの以下の行を、オブジェクトの spec セクションに追加します。

     nodeSelector:
       node-role.kubernetes.io/infra: ""

4. レジストリー Pod がインフラストラクチャーノードに移動していることを確認します。

   1. 以下のコマンドを実行して、レジストリー Pod が置かれているノードを特定します。

      $ oc get pods -o wide -n openshift-image-registry

   2. ノードに指定したラベルがあることを確認します。

      $ oc describe node <node_name>

      コマンド出力を確認し、node-role.kubernetes.io/infra が LABELS 一覧にあることを確認します。

手順

1. 以下の ConfigMap 定義を cluster-monitoring-configmap.yaml ファイルとして保存します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |+
       alertmanagerMain:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       prometheusK8s:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       prometheusOperator:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       grafana:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       k8sPrometheusAdapter:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       kubeStateMetrics:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       telemeterClient:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       openshiftStateMetrics:
         nodeSelector:
           node-role.kubernetes.io/infra: ""

   この ConfigMap を実行すると、モニタリングスタックのコンポーネントがインフラストラクチャーノードに再デプロイされます。

2. 新規の ConfigMap を適用します。

   $ oc create -f cluster-monitoring-configmap.yaml

3. モニタリング Pod が新規マシンに移行することを確認します。

   $ watch 'oc get pod -n openshift-monitoring -o wide'

4. コンポーネントが infra ノードに移動していない場合は、このコンポーネントを持つ Pod を削除します。

   $ oc delete pod -n openshift-monitoring <pod>

   削除された Pod からのコンポーネントが infra ノードに再作成されます。

手順

1. openshift-logging プロジェクトでクラスターロギングのカスタムリソースを編集します。

   $ oc edit ClusterLogging instance

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogging
   
   ....
   
   spec:
     collection:
       logs:
         fluentd:
           resources: null
         type: fluentd
     curation:
       curator:
         nodeSelector: 1
             node-role.kubernetes.io/infra: ''
         resources: null
         schedule: 30 3 * * *
       type: curator
     logStore:
       elasticsearch:
         nodeCount: 3
         nodeSelector: 2
             node-role.kubernetes.io/infra: ''
         redundancyPolicy: SingleRedundancy
         resources:
           limits:
             cpu: 500m
             memory: 16Gi
           requests:
             cpu: 500m
             memory: 16Gi
         storage: {}
       type: elasticsearch
     managementState: Managed
     visualization:
       kibana:
         nodeSelector: 3
             node-role.kubernetes.io/infra: '' 4
         proxy:
           resources: null
         replicas: 1
         resources: null
       type: kibana
   
   ....