インストール

手順

1. クラスターの Kubernetes マニフェストを生成します。

   $ ./openshift-install create manifests --dir=<installation_directory>

2. カーネル引数をワーカーまたはマスターノードに追加するかどうかを決定します。

3. openshift ディレクトリーでファイル（例: 99_openshift-machineconfig_master-kargs.yaml）を作成し、カーネル設定を追加するために MachineConfig オブジェクトを定義します。以下の例では、loglevel=7 カーネル引数をマスターノードに追加します。

   $ cat << EOF > 99_openshift-machineconfig_master-kargs.yaml
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: master
     name: 99_openshift-machineconfig_master-kargs
   spec:
     kernelArguments:
       - 'loglevel=7'
   EOF

   カーネル引数をワーカーノードに追加する場合は、master を worker に切り替えます。マスターおよびワーカーノードの両方に追加するために別々の YAML ファイルを作成します。

手順

1. chrony.conf ファイルのコンテンツを作成し、これを base64 でエンコードします。以下は例になります。

   $ cat << EOF | base64
       server clock.redhat.com iburst
       driftfile /var/lib/chrony/drift
       makestep 1.0 3
       rtcsync
       logdir /var/log/chrony
       EOF
   
   ICAgIHNlcnZlciBjbG9jay5yZWRoYXQuY29tIGlidXJzdAogICAgZHJpZnRmaWxlIC92YXIvbGli
   L2Nocm9ueS9kcmlmdAogICAgbWFrZXN0ZXAgMS4wIDMKICAgIHJ0Y3N5bmMKICAgIGxvZ2RpciAv
   dmFyL2xvZy9jaHJvbnkK

2. MachineConfig ファイルを作成します。base64 文字列を独自に作成した文字列に置き換えます。この例では、ファイルを master ノードに追加します。これを worker に切り替えたり、 worker ロールの追加の MachineConfig を作成したりできます。

   $ cat << EOF > ./99_masters-chrony-configuration.yaml
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: master
     name: masters-chrony-configuration
   spec:
     config:
       ignition:
         config: {}
         security:
           tls: {}
         timeouts: {}
         version: 2.2.0
       networkd: {}
       passwd: {}
       storage:
         files:
         - contents:
             source: data:text/plain;charset=utf-8;base64,c2VydmVyIGNsb2NrLnJlZGhhdC5jb20gaWJ1cnN0CmRyaWZ0ZmlsZSAvdmFyL2xpYi9jaHJvbnkvZHJpZnQKbWFrZXN0ZXAgMS4wIDMKcnRjc3luYwpsb2dkaXIgL3Zhci9sb2cvY2hyb255Cg==
             verification: {}
           filesystem: root
           mode: 420
           path: /etc/chrony.conf
     osImageURL: ""
   EOF

3. 設定ファイルのバックアップコピーを作成します。
4. クラスターがまだ起動していない場合は、マニフェストファイルを生成し、そのファイルを openshift ディレクトリーに追加してから、クラスターの作成を継続します。

5. クラスターがすでに実行中の場合は、ファイルを以下のように適用します。

    $ oc apply -f ./masters-chrony-configuration.yaml

1. Red Hat OpenShift Cluster Manager サイトの「Pull Secret」ページから registry.redhat.io プルシークレットをダウンロードし、これを .json ファイルに保存します。

2. ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードまたはトークンを生成します。

   $ echo -n '<user_name>:<password>' | base64 -w0 1
   BGVtbYk3ZHAtqXs=

   1

   <user_name> および <password> については、レジストリーに設定したユーザー名およびパスワードを指定します。

3. JSON 形式でプルシークレットのコピーを作成します。

   $ cat ./pull-secret.text | jq .  > <path>/<pull-secret-file>1

   1

   プルシークレットを保存するフォルダーへのパスおよび作成する JSON ファイルの名前を指定します。

   ファイルの内容は以下の例のようになります。

   {
     "auths": {
       "cloud.openshift.com": {
         "auth": "b3BlbnNo...",
         "email": "you@example.com"
       },
       "quay.io": {
         "auth": "b3BlbnNo...",
         "email": "you@example.com"
       },
       "registry.connect.redhat.com": {
         "auth": "NTE3Njg5Nj...",
         "email": "you@example.com"
       },
       "registry.redhat.io": {
         "auth": "NTE3Njg5Nj...",
         "email": "you@example.com"
       }
     }
   }

4. 新規ファイルを編集し、レジストリーについて記述するセクションをこれに追加します。

     "auths": {
       "<mirror_registry>": { 1
         "auth": "<credentials>", 2
         "email": "you@example.com"
     },

   1

   <mirror_registry> については、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例: registry.example.com または registry.example.com:5000

   2

   <credentials> については、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。

   ファイルは以下の例のようになります。

   {
     "auths": {
       "<mirror_registry>": {
         "auth": "<credentials>",
         "email": "you@example.com"
       },
       "cloud.openshift.com": {
         "auth": "b3BlbnNo...",
         "email": "you@example.com"
       },
       "quay.io": {
         "auth": "b3BlbnNo...",
         "email": "you@example.com"
       },
       "registry.connect.redhat.com": {
         "auth": "NTE3Njg5Nj...",
         "email": "you@example.com"
       },
       "registry.redhat.io": {
         "auth": "NTE3Njg5Nj...",
         "email": "you@example.com"
       }
     }
   }

1. 新規ファイルを編集し、レジストリーについて記述するセクションをこれに追加します。

     "auths": {
   ...
       "<mirror_registry>": { 1
         "auth": "<credentials>", 2
         "email": "you@example.com"
     },
   ...

   1

   <mirror_registry> については、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例: registry.example.com または registry.example.com:5000

   2

   <credentials> については、ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。

   ファイルは以下の例のようになります。

   {
     "auths": {
       "cloud.openshift.com": {
         "auth": "b3BlbnNo...",
         "email": "you@example.com"
       },
       "quay.io": {
         "auth": "b3BlbnNo...",
         "email": "you@example.com"
       },
       "registry.connect.redhat.com": {
         "auth": "NTE3Njg5Nj...",
         "email": "you@example.com"
       },
       "<mirror_registry>": {
         "auth": "<credentials>",
         "email": "you@example.com"
       },
       "registry.redhat.io": {
         "auth": "NTE3Njg5Nj...",
         "email": "you@example.com"
       }
     }
   }

1. 「OpenShift Container Platform ダウンロード」ページを確認し、インストールする必要のある OpenShift Container Platform のバージョンを判別し、「Repository Tags」ページで対応するタグを判別します。

2. 必要な環境変数を設定します。

   $ export OCP_RELEASE=<release_version> 1
   $ export LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>' 2
   $ export LOCAL_REPOSITORY='<local_repository_name>' 3
   $ export PRODUCT_REPO='openshift-release-dev' 4
   $ export LOCAL_SECRET_JSON='<path_to_pull_secret>' 5
   $ export RELEASE_NAME="ocp-release" 6
   $ export ARCHITECTURE=<server_architecture> 7
   $ REMOVABLE_MEDIA_PATH=<path> 8

   1

   <release_version> について、ご使用のアーキテクチャー用にインストールする OpenShift Container Platform のバージョンに対応するタグを指定します (例: 4.3.0)。

   2

   <local_registry_host_name> については、ミラーレジストリーのレジストリードメイン名を指定し、<local_registry_host_port> については、コンテンツの送信に使用するポートを指定します。

   3

   <local_repository_name> については、ocp4/openshift4 などのレジストリーに作成するリポジトリーの名前を指定します。

   4

   ミラーリングするリポジトリー。実稼働環境のリリースの場合には、openshift-release-devを指定する必要があります。

   5

   <path_to_pull_secret>については、作成したミラーレジストリーのプルシークレットおよびファイル名の絶対パスを指定します。

   6

   リリースミラー。実稼働環境のリリースについては、ocp-releaseを指定する必要があります。

   7

   server_architecture について、サーバーのアーキテクチャー (例: x86_64) を指定します。

   8

   <path> について、ミラーリングされたイメージをホストするためのディレクトリーへのパスを指定します。

3. バージョンイメージを内部コンテナーレジストリーにミラーリングします。

   • ミラーホストがインターネットにアクセスできない場合は、以下の操作を実行します。

     1. リムーバブルメディアをインターネットに接続しているシステムに接続します。

     2. ミラーリングするイメージおよび設定マニフェストを確認します。

        $ oc adm -a ${LOCAL_SECRET_JSON} release mirror
        --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}
        --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}
        --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} --run-dry

     3. 直前のコマンドの出力の imageContentSources セクション全体を記録します。ミラーの情報はミラーリングされたリポジトリーに一意であり、インストール時に imageContentSources セクションを install-config.yaml ファイルに追加する必要があります。

     4. イメージをリムーバブルメディア上のディレクトリーにミラーリングします。

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}

     5. メディアをネットワークが制限された環境に移し、イメージをローカルコンテナーレジストリーにアップロードします。

        $ oc image mirror -a ${LOCAL_SECRET_JSON} --from-dir=${REMOVABLE_MEDIA_PATH}/mirror "file://openshift/release:${OCP_RELEASE}*" ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}

   • ローカルコンテナーレジストリーがミラーホストに接続されている場合は、以下の操作を実行します。

     1. 以下のコマンドを使用して、リリースイメージをローカルレジストリーに直接プッシュします。

        $ oc adm -a ${LOCAL_SECRET_JSON} release mirror \
             --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \
             --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \
             --to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}

        このコマンドは、リリース情報をダイジェストとしてプルします。その出力には、クラスターのインストール時に必要な imageContentSources データが含まれます。

     2. 直前のコマンドの出力の imageContentSources セクション全体を記録します。ミラーの情報はミラーリングされたリポジトリーに一意であり、インストール時に imageContentSources セクションを install-config.yaml ファイルに追加する必要があります。

1. ミラーリングしたコンテンツをベースとしているインストールプログラムを作成するには、これを展開し、リリースに固定します。

   $ oc adm -a ${LOCAL_SECRET_JSON} release extract --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"

   重要

   選択した OpenShift Container Platform バージョンに適したイメージを使用するには、ミラーリングされたコンテンツからインストールプログラムを展開する必要があります。

   インターネット接続のあるマシンで、このステップを実行する必要があります。

手順

1. インストールペイロードからデフォルトの must-gather イメージをインポートします。

   $ oc import-image is/must-gather -n openshift

手順

1. ミラーリングする特定のイメージストリームのイメージにアクセスします。

   $ oc get is <imagestream> -n openshift -o json | jq .spec.tags[].from.name | grep registry.redhat.io

2. ネットワークが制限された環境で必要とするイメージストリームに関連付けられた registry.redhat.io のイメージを定義されたミラーのいずれかにミラーリングします。

   $ oc image mirror registry.redhat.io/rhscl/ruby-25-rhel7:latest ${MIRROR_ADDR}/rhscl/ruby-25-rhel7:latest

3. クラスターのイメージ設定オブジェクトに、ミラーに必要な信頼される CA を追加します。

   $ oc create configmap registry-config --from-file=${MIRROR_ADDR_HOSTNAME}..5000=$path/ca.crt -n openshift-config
   $ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-config"}}}' --type=merge

4. Samples Operator 設定オブジェクトの samplesRegistry フィールドを、ミラー設定で定義されたミラーの場所の hostname の部分を含むように更新します。

   $ oc edit configs.samples.operator.openshift.io -n openshift-cluster-samples-operator

   注記

   これは、イメージストリームのインポートプロセスでミラーまたは検索メカニズムが使用されないので必要になります。

5. Samples Operator 設定オブジェクトの skippedImagestreams フィールドにミラーリングされないイメージストリームを追加します。または、サンプルイメージストリームのいずれもサポートする必要がない場合は、Samples Operator を Samples Operator 設定オブジェクトの Removed に設定します。

   注記

   省略されないミラーリングされないイメージがあるか、または Samples Operator が Removed に変更されない場合、 Samples Operator はイメージストリームのインポートが失敗し始めてから 2 時間後に Degraded ステータスを報告します。

   OpenShift namespace のテンプレートの多くはイメージストリームを参照します。そのため、Removed を使用してイメージストリームとテンプレートの両方を除去すると、イメージストリームのいずれかが欠落しているためにテンプレートが正常に機能しない場合にテンプレートの使用を試行する可能性がなくなります。

手順

1. 以下のレジストリー URL を許可リストに指定します。

   URL	関数
   registry.redhat.io	コアコンテナーイメージを指定します。
   quay.io	コアコンテナーイメージを指定します。
   sso.redhat.com	https://cloud.redhat.com/openshift サイトでは、 sso.redhat.com からの認証を使用します。
   openshift.org	Red Hat Enterprise Linux CoreOS (RHCOS) イメージを提供します。

2. ビルドに必要な言語またはフレームワークのリソースを提供するサイトを許可リストに指定します。

3. Telemetry を無効にしていない場合は、以下の URL へのアクセスを許可して Red Hat Insights にアクセスできるようにする必要があります。

   URL	関数
   cert-api.access.redhat.com	Telemetry で必須
   api.access.redhat.com	Telemetry で必須
   infogw.api.openshift.com	Telemetry で必須
   https://cloud.redhat.com/api/ingress	Telemetry および insights-operator で必須

4. Amazon Web Services (AWS) 、Microsoft Azure、または Google Cloud Platform (GCP) を使用してクラスターをホストする場合、クラウドプロバイダー API およびそのクラウドの DNS を提供する URL へのアクセスを付与する必要があります。

   クラウド	URL	関数
   AWS	*.amazonaws.com	AWS サービスおよびリソースへのアクセスに必要です。AWS ドキュメントの「AWS Service Endpoints」を参照し、使用するリージョンを許可するエンドポイントを判別します。
   GCP	*.googleapis.com	GCP サービスおよびリソースへのアクセスに必要です。GCP ドキュメントの「 Cloud Endpoints」を参照し、API を許可するエンドポイントを判別します。
   	accounts.google.com	GCP アカウントへのアクセスに必要です。
   Azure	management.azure.com	Azure サービスおよびリソースへのアクセスに必要です。Azure ドキュメントで「Azure REST API Reference」を参照し、API を許可するエンドポイントを判別します。

5. 以下の URL を許可リストに指定します。

   URL	関数
   mirror.openshift.com	ミラーリングされたインストールのコンテンツおよびイメージへのアクセスに必要。Cluster Version Operator には単一の機能ソースのみが必要ですが、このサイトはリリースイメージ署名のソースでもあります。
   storage.googleapis.com/openshift-release	リリースイメージ署名のソース (ただし、Cluster Version Operator には単一の機能ソースのみが必要)。
   *.apps.<cluster_name>.<base_domain>	Ingress ワイルドカードをインストール時に設定しない限り、デフォルトのクラスタールートへのアクセスに必要。
   quay-registry.s3.amazonaws.com	AWS で Quay イメージコンテンツにアクセスするために必要。
   api.openshift.com	クラスターに更新が利用可能かどうかを確認するために必要。
   art-rhcos-ci.s3.amazonaws.com	Red Hat Enterprise Linux CoreOS (RHCOS) イメージをダウンロードするために必要。
   api.openshift.com	クラスタートークンに必須
   cloud.redhat.com/openshift	クラスタートークンに必須

   Operator にはヘルスチェックを実行するためのルートアクセスが必要です。具体的には、認証および Web コンソール Operator は 2 つのルートに接続し、ルートが機能することを確認します。クラスター管理者として操作を実行しており、*.apps.<cluster_name>.<base_domain> を許可しない場合は、これらのルートを許可します。

   • oauth-openshift.apps.<cluster_name>.<base_domain>
   • console-openshift-console.apps.<cluster_name>.<base_domain>、またはフィールドが空でない場合に consoles.operator/cluster オブジェクトの spec.route.hostname フィールドに指定されるホスト名。

手順

1. クラスターの DNS カスタムリソースを確認します。

   $ oc get dnses.config.openshift.io/cluster -o yaml
   apiVersion: config.openshift.io/v1
   kind: DNS
   metadata:
     creationTimestamp: "2019-10-25T18:27:09Z"
     generation: 2
     name: cluster
     resourceVersion: "37966"
     selfLink: /apis/config.openshift.io/v1/dnses/cluster
     uid: 0e714746-f755-11f9-9cb1-02ff55d8f976
   spec:
     baseDomain: <base_domain>
     privateZone:
       tags:
         Name: <infrastructureID>-int
         kubernetes.io/cluster/<infrastructureID>: owned
     publicZone:
       id: Z2XXXXXXXXXXA4
   status: {}

   spec セクションには、プライベートゾーンとパブリックゾーンの両方が含まれることに注意してください。

2. DNS カスタムリソースにパッチを適用して、パブリックゾーンを削除します。

   $ oc patch dnses.config.openshift.io/cluster --type=merge --patch='{"spec": {"publicZone": null}}'
   dns.config.openshift.io/cluster patched

   Ingress コントローラーは Ingress オブジェクトの作成時に DNS 定義を参照するため、Ingress オブジェクトを作成または変更する場合、プライベートレコードのみが作成されます。

   重要

   既存の Ingress オブジェクトの DNS レコードは、パブリックゾーンの削除時に変更されません。

3. オプション: クラスターの DNS カスタムリソースを確認し、パブリックゾーンが削除されていることを確認します。

   $ oc get dnses.config.openshift.io/cluster -o yaml
   apiVersion: config.openshift.io/v1
   kind: DNS
   metadata:
     creationTimestamp: "2019-10-25T18:27:09Z"
     generation: 2
     name: cluster
     resourceVersion: "37966"
     selfLink: /apis/config.openshift.io/v1/dnses/cluster
     uid: 0e714746-f755-11f9-9cb1-02ff55d8f976
   spec:
     baseDomain: <base_domain>
     privateZone:
       tags:
         Name: <infrastructureID>-int
         kubernetes.io/cluster/<infrastructureID>-wfpg4: owned
   status: {}

手順

1. 内部エンドポイントのみを使用するようにデフォルト Ingress コントローラーを変更します。

   $ oc replace --force --wait --filename - <<EOF
   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     namespace: openshift-ingress-operator
     name: default
   spec:
     endpointPublishingStrategy:
       type: LoadBalancerService
       loadBalancer:
         scope: Internal
   EOF
   ingresscontroller.operator.openshift.io "default" deleted
   ingresscontroller.operator.openshift.io/default replaced

   パブリック DNS エントリーが削除され、プライベートゾーンエントリーが更新されます。

手順

1. AWS または Azure の Web ポータルまたはコンソールで、以下のアクションを実行します。

   1. 適切なロードバランサーコンポーネントを見つけ、削除します。

      • AWS の場合は、外部ロードバランサーを削除します。プライベートゾーンの API DNS エントリーは、同一の設定を使用する内部ロードバランサーをすでに参照するため、内部ロードバランサーを変更する必要はありません。
      • Azure の場合、ロードバランサーの api-internal ルールを削除します。
   2. パブリックゾーンの api.$clustername.$yourdomain DNS エントリーを削除します。

2. ターミナルで、クラスターマシンを一覧表示します。

   $ oc get machine -n openshift-machine-api
   NAME                            STATE     TYPE        REGION      ZONE         AGE
   lk4pj-master-0                  running   m4.xlarge   us-east-1   us-east-1a   17m
   lk4pj-master-1                  running   m4.xlarge   us-east-1   us-east-1b   17m
   lk4pj-master-2                  running   m4.xlarge   us-east-1   us-east-1a   17m
   lk4pj-worker-us-east-1a-5fzfj   running   m4.xlarge   us-east-1   us-east-1a   15m
   lk4pj-worker-us-east-1a-vbghs   running   m4.xlarge   us-east-1   us-east-1a   15m
   lk4pj-worker-us-east-1b-zgpzg   running   m4.xlarge   us-east-1   us-east-1b   15m

   以下の手順で、名前に master が含まれるコントロールプレーンマシンを変更します。

3. 各コントロールプレーンマシンから外部ロードバランサーを削除します。

   1. master Machine オブジェクトを編集し、外部ロードバランサーへの参照を削除します。

      $ oc edit machines -n openshift-machine-api <master_name> 1

      1

      変更するコントロールプレーン、またはマスター、マシンの名前を指定します。

   2. 以下の例でマークが付けられている外部ロードバランサーを記述する行を削除し、オブジェクト仕様を保存し、終了します。

      ...
      spec:
        providerSpec:
          value:
          ...
            loadBalancers:
            - name: lk4pj-ext 1
              type: network 2
            - name: lk4pj-int
              type: network

      1 2

      この行を削除します。

   3. 名前に master が含まれるマシンにこのプロセスを繰り返します。