1.9. 既知の問題

OpenShift Container Platform 4.1 では、匿名ユーザーは検出エンドポイントにアクセスできました。後のリリースでは、一部の検出エンドポイントは集約された API サーバーに転送されるため、このアクセスを無効にして、セキュリティーの脆弱性の可能性を減らすことができます。ただし、既存のユースケースに支障がで出ないように、認証されていないアクセスはアップグレードされたクラスターで保持されます。

OpenShift Container Platform 4.1 から 4.8 にアップグレードされたクラスターのクラスター管理者の場合、認証されていないアクセスを無効にするか、またはこれを引き続き許可することができます。特定の必要がなければ、認証されていないアクセスを無効にすることが推奨されます。認証されていないアクセスを引き続き許可する場合は、それに伴ってリスクが増大することに注意してください。

以下のスクリプトを使用して、検出エンドポイントへの認証されていないアクセスを無効にします。

## Snippet to remove unauthenticated group from all the cluster role bindings
$ for clusterrolebinding in cluster-status-binding discovery system:basic-user system:discovery system:openshift:discovery ;
do
### Find the index of unauthenticated group in list of subjects
index=$(oc get clusterrolebinding ${clusterrolebinding} -o json | jq 'select(.subjects!=null) | .subjects | map(.name=="system:unauthenticated") | index(true)');
### Remove the element at index from subjects array
oc patch clusterrolebinding ${clusterrolebinding} --type=json --patch "[{'op': 'remove','path': '/subjects/$index'}]";
done

このスクリプトは、認証されていないサブジェクトを以下のクラスターロールバインディングから削除します。

(BZ#1821771)

ユーザーによってプロビジョニングされるインフラストラクチャーで vSphere 上の仮想マシンの電源をオンにすると、ノードのスケールアッププロセスは予想通りに機能しない可能性があります。ハイパーバイザー設定の既知の問題により、ハイパーバイザー内にマシンが作成されますが、電源がオンになりません。マシンセットをスケールアップした後にノードが Provisioning 状態のままである場合、vSphere インスタンス自体で仮想マシンのステータスを調査できます。VMware コマンド govc tasks および govc events を使用して、仮想マシンのステータスを判別します。以下のようなエラーメッセージがあるかどうかを確認します。

Invalid memory setting: memory reservation (sched.mem.min) should be equal to memsize(8192).

この VMware KBase の記事 にある手順に従って、問題の解決を試行できます。詳細は、Red Hat ナレッジベースのソリューションの UPI vSphere Node scale-up doesn't work as expected を参照してください。(BZ#1918383)

ArgoCD Operator がサブスクライブされ、ArgoCD と AppProject が開始されると、より制限の厳しい OpenShift Container Platform 環境でイメージが機能しないため、guestbook という名前のサンプルアプリケーションの起動に失敗します。一時的な回避策として、ユーザーは以下の例をデプロイすることで、ArgoCD Operator が正しく機能することを確認できます。

PROJ=younamespace
cat > $PROJ-app.yaml <<EOF
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: simple-restricted-webserver
  namespace: $PROJ
spec:
  destination:
    namespace: $PROJ
    server: https://kubernetes.default.svc
  project: default
  source:
    path: basic-nginx
    repoURL: 'https://github.com/opdev/argocd-example-restricted-apps.git'
    targetRevision: HEAD
EOF
oc create -f $PROJ-app.yaml

詳細は、BZ#1812212 を参照してください。

pathType: Prefix を使用すると、Ingress を使用したパススルールートの作成が失敗します。代わりに、pathType を ImplementationSpecific に設定し、path を '' に設定することで、パススルールートを作成できます。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress7
  namespace: test-ingress
  annotations:
    route.openshift.io/termination: passthrough
spec:
  rules:
  - host: <ingress-psql-example-test-ingress.apps>
    http:
      paths:
      - path: ''
        pathType: ImplementationSpecific
        backend:
          service:
            name: <ingress-psql-example>
            port:
              number: 8080

詳細は、BZ#1878685 を参照してください。

OpenShift Container Platform 4.8 以前のデフォルトのロードバランシングアルゴリズムは leastconn でした。パススルーでないルートの場合、OpenShift Container Platform 4.8.0 ではデフォルトが random に変更されました。random に切り替えると、長時間のウェブソケット接続を使用する必要がある環境では、メモリー消費量が大幅に増加するため、互換性がありません。この大幅なメモリー消費を軽減するために、OpenShift Container Platform 4.8 では、デフォルトのロードバランシングアルゴリズムが leastconn に戻されました。大幅なメモリー使用量を発生させないソリューションが開発されれば、OpenShift Container Platform の将来のリリースでデフォルトが random に変更される予定です。

以下のコマンドを入力することで、デフォルトの設定を確認することができます。

$ oc get deployment -n openshift-ingress router-default -o yaml | grep -A 2 ROUTER_LOAD_BALANCE_ALGORITHM
        - name: ROUTER_LOAD_BALANCE_ALGORITHM
          value: leastconn

random のオプションはまだ利用可能です。しかし、このアルゴリズムの選択の恩恵を受けたいルートは、以下のコマンドを入力して、ルートごとにアノテーションでそのオプションを明示的に設定する必要があります。

$ oc annotate -n <NAMESPACE> route/<ROUTE-NAME> "haproxy.router.openshift.io/balance=random"

(BZ#2017708)

4.7 OpenShift Container Platform クラスターから 4.8 にアップグレードした後、OpenShift Container Platform ノードのセカンダリーネットワークインターフェイスコントローラー (NIC) を介した内部ネットワークから外部ネットワーク Pod へのルーティングパスは、デフォルトで無効になります。これは、共有ゲートウェイが 4.8 以降の Open Virtual Network (OVN) 設計のデフォルトゲートウェイモードであるためです。そのルーティングパスが必要な場合は、アップグレードの前後に回避策として、openshift-network-operator namespace に gateway-mode-config 設定マップを作成して、OVN ゲートウェイモードをローカルに強制します。

以下のコマンドを入力して、openshift-network-operator namespace に gateway-mode-config を作成します。

$ cat localGW.yml

apiVersion: v1
kind: ConfigMap
metadata:
    name: gateway-mode-config
    namespace: openshift-network-operator
data:
    mode: "local"
immutable: true

$ oc apply -f localGW.yml

configmap/gateway-mode-config created

追加のガイダンスについては、(KCS) および (BZ#2089389) を参照してください。将来のリリースでこの設定をさらに対処する予定です。