設定ステップ
このセクションのトピック:
- Kubernetesクラスタの設定
- 環境の準備
- データベースおよび適切なデータベース・サービスの作成
- DMZでのOracle HTTP Serverのインストールおよび構成
- フロントエンド・ロード・バランサの構成
- Coherenceのオペレーティング・システム変更の適用
- リポジトリ作成ユーティリティの実行によるデータベース・スキーマの設定
- WebLogic Kubernetes OperatorおよびOracle SOA Suiteのデプロイ
- Oracle SOA Suiteドメインのカスタム・キーストアの構成
- Oracle HTTP Serverでのカスタム証明書の使用
- 冗長永続ボリュームの構成
- フロントエンド・アドレスの設定
- GridLinkデータ・ソースのFANの有効化
- ASMの構成
- coredns割当ての構成
- サーバーのポッドの有効性プローブの調整
Kubernetesクラスタの設定
Kubernetesコントロール・プレーン(マスター・ノード)の環境の準備
-
ロード・バランサ(LBR)のL4/TCPリスナーを作成します。
-
追加されるコントロール・プレーン・ノードのリストを使用して、LBRバックエンド・プールを作成します(IPは使用せず、常にホスト名を使用します)。
ノート:
次のkube-apiバックエンド・プール・パラメータの値を所定の範囲内に維持して、Kubernetesコントロール・プレーンの再起動時またはメンテナンス操作の実行時の停止時間を最小限に抑えることをお薦めします。- ヘルスチェック間隔: 1000ミリ秒以内
- ヘルスチェック・タイムアウト: 900ミリ秒以内
-
L4 LBRによるバックエンド・セット/プールへのルーティングを有効にします。
ノート:
これは、HTTP/HTTPSリスナーではなく、L4/TCPリスナーであることが重要です。 -
ノードが準備完了状態であることを確認します。
-
sshキーを作成します(共通sshキーを使用して、設定を実行しているノードからコントロール・プレーン・ノードへのアクセスを有効にします)。
-
コントロール・プレーン・ノードとフロントエンドLBRの間の中間ファイアウォールでのトラフィックを許可します。必要なポートについては、Kubernetesのドキュメントを参照してください。
- 3つのマスター・ノードと3つのMinionノードを持つHAクラスタを作成します。設定については、「Stacked etcd Topology」を含むドキュメントを参照してください。
環境の準備
ファイアウォールとネットワークの構成
- ロード・バランサ(LBR)から、構成されるOracle HTTP Server (OHS)ポート(OHSの場合はデフォルトで7777)へのトラフィックを許可します。
- OHSから、管理サーバー(30701)、SOAクラスタ(30801)およびService Busクラスタ(30901)のワーカー・ノードで構成されるノード・ポートへのトラフィックを許可します。
- ワーカー・ノードから、コントロール・プレーン・フロントエンドの
kube-api仮想サーバー・ポートおよびフロントエンドのOracle SOA Suiteへのトラフィックを許可します。 - ワーカー・ノードからデータベース・リスナーおよびONSポート(デフォルトではそれぞれ1521および6200)へのトラフィックを許可します。
オンプレミスの『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』をリファレンスとして使用できます。
すべてのワーカー・ノードへのOracle SOA Suiteイメージのロード
各ワーカー・ノードにイメージをロードし、適切にタグ付けするには、「Oracle SOA Suite Dockerイメージの取得」を参照してください。
永続ボリュームの共有ストレージの場所の有効化
共有ストレージ・デバイスは、異なるワーカー・ノードから使用する必要があります。このストレージは、Oracle SOA Suiteドメイン・ディレクトリをホストします。最初は、単一のストレージの場所を使用して、Oracle SOA Suiteドメインをホストする永続ボリュームを作成します。すべてのワーカー・ノードで同じマウント・パスを使用して、この共有ストレージ(NFS/NAS)をマウントします。
たとえば、すべてのワーカー・ノードのNFS1 (10.10.0.21:/k8nfs)を共有ディレクトリ/k8nfsにマウントします:
$ grep "k8nfs nfs" /etc/fstab
10.10.0.21:/k8nfs /k8nfs nfs rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.21,mountvers=3,mountport=2048,mountproto=udp,local_lock=none,addr=10.10.0.21後で、高可用性を実現するために2番目のストレージの場所を構成するステップを示します。
データベースおよび適切なデータベース・サービスの作成
RACデータベースのインストールおよび作成はこのドキュメントの範囲外です。データベースを構成したら、中間層からスキーマにアクセスするための適切なサービスを作成する必要があります。Oracle SOA Suiteでは、正確な非デフォルト/管理サービスを作成することが重要です。『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド14.1.2.0.0』の「エンタープライズ・デプロイメント用のデータベースの準備」を参照してください。
DMZでのOracle HTTP Serverのインストールおよび構成
『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のステップに従って、ワーカー・ノードとは別のノードに2つのOracle HTTP Server (OHS)インスタンスを作成します。バックエンドのKubernetes Oracle SOA SuiteまたはService BusサーバーでOHSを構成するには、30000 - 32767の範囲のポートを使用する必要があります。このポートは、後でOracle SOA Suite構成スクリプトで使用します。
このKubernetesエンタープライズ・デプロイメント・ガイドでは、OHSは、SOAドメイン内の個別のOracle SOA Suite/Service Busクラスタごとに構成されたノード・ポートにルーティングします。その後、OHSはこれらのノード・ポートにルーティングし、そこから関連サーバー・ポッドにリダイレクトされます。ノード・ポートは実際にはWebLogicリスナーではなく、使用可能なWebLogicサーバーのインテリジェント・リストを保持するノード・ポート構成であるため、構成のOHSディレクティブではDynamicServerListを無効にする必要があります。OHSのsoa-infraマウントのOHSディレクティブは次のようになります:
<Location /soa-infra>
WLSRequest ON
WebLogicCluster workernode1:30801,workernode2:30801,workernode3:30801
</Location>同様に、他のパスの他のディレクティブも同様のノード・ポート・アドレスを反映する必要があります。
フロントエンド・ロード・バランサの構成
BigIp F5 LBR、またはCISCOなどの任意の標準LBRを使用できます。必要な仮想サーバーについては、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』(「エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備」)を参照してください。オンプレミスのエンタープライズ・デプロイメント・ガイドでは、サービスおよびトラフィックの最適な分離に使用できる仮想サーバー/リスナーの詳細なリストを提供しています。Kubernetesの場合は、少なくとも、OHSリスナーをバックエンド・プールとして使用したOracle SOA Suiteの仮想サーバー/リスナーが必要です。
-
ロード・バランサのL7/httpsリスナーを作成します。
-
Oracle SOA Suiteで使用されるOHSノード/ポートのリストを含むバックエンド・プールを作成します(IPは使用せず、常にホスト名を使用します)。
-
L7/httpsリスナー・ロード・バランサによるOHSバックエンド・セット/プールへのルーティングを有効にします。
-
OHSプールにルーティングするようにフロントエンド・ロード・バランサを構成します。
ノート:
BPMワークリスト(/integration/worklistapp)、SOAコンポーザ(/soa/composer)など、SOAの一部のWebアプリケーションにはセッション永続性が必要であるため、Cookieベースの永続性のためにLBRを構成することをお薦めします。
Coherenceのオペレーティング・システム変更の適用
Coherenceでは、Kubernetes環境でクラスタを作成するには特定の設定が必要です。WebLogic Kubernetes Operatorのドキュメントに記載されているステップを参照してください。
リポジトリ作成ユーティリティの実行によるデータベース・スキーマの設定
Oracle SOA Suiteのデータベース・スキーマを作成するには、SOA_PROFILE_TYPE=LARGEを指定してcreate-rcu-schema.shスクリプトを実行します。コマンド例を次に示します
./create-rcu-schema.sh \
-s SOA1 \
-t soaosb \
-d oracle-db.default.svc.cluster.local:1521/devpdb.k8s \
-n default \
-c oracle-rcu-secret \
-b EBR \
-i soasuite:release-version \
-r SOA_PROFILE_TYPE=LARGE,HEALTHCARE_INTEGRATION=NOWebLogic Kubernetes OperatorおよびOracle SOA Suiteのデプロイ
WebLogic Kubernetes Operatorのインストール、Oracle SOA Suiteドメインの環境の準備、Oracle SOA Suiteドメインの作成に関する項のステップに従います
Oracle SOA Suiteドメインが正常に作成され、サーバーを起動したら、ポッドおよび作成された様々なサービスを確認します。Oracle SOA Suiteの管理対象サーバーがRUNNING状態(ポッドの準備完了)になったら、フロントエンド・ロード・バランサを使用して一般的なOracle SOA Suite URLを確認します。
sessionAffinityをClientIPにして、管理サーバー、SOAクラスタおよびOSBクラスタのNodeportサービスを作成します。次に、soaクラスタ用のNodeportサービスのサンプルを示します:
$ cat soa-nodeport.yaml
apiVersion: v1
kind: Service
metadata:
name: soainfra-soa-nodeport-service
namespace: soans
labels:
weblogic.domainUID: soainfra
weblogic.clusterName: soa_cluster
spec:
type: NodePort
sessionAffinity: ClientIP
ports:
- port: 7004
protocol: TCP
targetPort: 7004
nodePort: 30234
selector:
weblogic.domainUID: soainfra
weblogic.clusterName: soa_clusterSOAポッドおよびサービスがデプロイされ、準備が完了します:
$ kubectl get all -n soans
NAME READY STATUS RESTARTS AGE
pod/soaedgdomain-adminserver 1/1 Running 0 47h
pod/soaedgdomain-create-soa-infra-domain-job-6pq9z 0/1 Completed 0 68d
pod/soaedgdomain-soa-server1 1/1 Running 0 2d2h
pod/soaedgdomain-soa-server2 1/1 Running 0 2d2h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/soaedgdomain-adminserver ClusterIP None <none> 30012/TCP,7001/TCP 2d4h
service/soaedgdomain-adminserver-ext NodePort 10.104.20.22 <none> 30012:30012/TCP,7001:30701/TCP 31d
service/soaedgdomain-cluster-osb-cluster ClusterIP 10.100.97.127 <none> 8002/TCP 68d
service/soaedgdomain-cluster-soa-cluster ClusterIP 10.101.101.113 <none> 7003/TCP 68d
service/soaedgdomain-cluster-soa-cluster-node-port NodePort 10.105.51.223 <none> 7003:30801/TCP 68d
service/soaedgdomain-osb-server1 ClusterIP 10.110.81.153 <none> 8002/TCP 2d4h
service/soaedgdomain-osb-server2 ClusterIP 10.103.220.112 <none> 8002/TCP 2d4h
service/soaedgdomain-osb-server3 ClusterIP 10.97.50.117 <none> 8002/TCP 2d4h
service/soaedgdomain-osb-server4 ClusterIP 10.98.48.247 <none> 8002/TCP 2d4h
service/soaedgdomain-osb-server5 ClusterIP 10.102.137.176 <none> 8002/TCP 2d4h
service/soaedgdomain-soa-server1 ClusterIP None <none> 7003/TCP 2d4h
service/soaedgdomain-soa-server2 ClusterIP None <none> 7003/TCP 2d4h
service/soaedgdomain-soa-server3 ClusterIP 10.105.108.74 <none> 7003/TCP 2d4h
service/soaedgdomain-soa-server4 ClusterIP 10.109.191.102 <none> 7003/TCP 2d4h
service/soaedgdomain-soa-server5 ClusterIP 10.107.2.99 <none> 7003/TCP 2d4h
NAME COMPLETIONS DURATION AGE
job.batch/soaedgdomain-create-soa-infra-domain-job 1/1 4m24s 68dOracle SOA Suiteドメインのカスタム・キーストアの構成
${WORKDIR}/custom-keystoreにあるヘルパー・スクリプトcustom-keystore.shを実行して、Oracle SOA Suiteドメインのカスタム・キーストアを構成します。
「デモCA証明書のドメインCA署名証明書との置換」を参照してください。
Oracle HTTP Serverでのカスタム証明書の使用
trust.p12 (custom-keystore.shで作成)をOHSにコピーします。次のコマンドは、OHSでキーとウォレットを管理する場合に役立ちます。
Java KeyStore (JKS)またはPKCS12キーストア・ファイルから証明書をエクスポートします。
$ keytool -export -keystore trust.p12 -storepass trustKeyStorePassword -alias trustcert1 -file trust.crt
Certificate stored in file <trust.crt>OHSのウォレットを作成するコマンド
$ orapki wallet create -wallet WLSSLWalletEDG -auto_login -pwd *****
Oracle PKI Tool Release 23.0.0.0.0 - Production
Version 23.0.0.0.0
Copyright (c) 2004, 2024, Oracle and/or its affiliates. All rights reserved.
Operation is successfully completed.信頼できる証明書をウォレットに追加します
$ orapki wallet add -wallet WLSSLWalletEDG -trusted_cert -cert trust.crt -pwd *****
Oracle PKI Tool Release 23.0.0.0.0 - Production
Version 23.0.0.0.0
Copyright (c) 2004, 2024, Oracle and/or its affiliates. All rights reserved.
Operation is successfully completed.$WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/mod_wl_ohs.confを変更して、次のように(SSLでのWLSバックエンドへのルーティングに必要とされる)適切なWLSSWalletファイルを含めます:
# NOTE : This is a template to configure mod_weblogic.
LoadModule weblogic_module "${PRODUCT_HOME}/modules/mod_wl_ohs.so"
# This empty block is needed to save mod_wl related configuration from EM to this file when changes are made at the Base Virtual Host Level
<IfModule weblogic_module>
WLIOTimeoutSecs 900
KeepAliveSecs 290
FileCaching OFF
WLSocketTimeoutSecs 15
ErrorPage http://www.oracle.com/splash/cloud/index.html
WLRetryOnTimeout NONE
WLForwardUriUnparsed On
SecureProxy On
WLSSLWallet "/u02/oracle/config/keystores/WLSSLWalletEDG"
</IfModule>冗長永続ボリュームの構成
Oracle SOA SuiteまたはService BusのポッドをKubernetesクラスタ内で移動する柔軟性を高めるために、ノード・セレクタを使用します。奇数のサーバー・ポッド(soa_server1、soa_server3、soa_server5など)がノード・セレクタ1に割り当てられ、偶数のサーバー・ポッド(soa_server2、soa_server4、soa_server6など)がノード・セレクタ2に割り当てられます。結果として得られる構成は次のとおりです:
図10-2 冗長永続ボリュームの構成
この構成を使用するには、次のステップを実行します:
-
Oracle SOA Suiteドメインを停止します。ドメインを起動および停止するスクリプトを参照してください。
-
上の図のように、すべての偶数ワーカー・ノードにNFS1を、すべての奇数ワーカー・ノードにNFS2をマウントします。例:
MOUNT ON ODD NODE [opc@olk8-w1 ~]$ grep "k8nfs nfs" /etc/fstab 10.10.0.21:/k8nfs /k8nfs nfs rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.21,mountvers=3,mountport=2048,mountproto=udp,local_lock=none,addr=10.10.0.21 MOUNT ON EVEN NODE [opc@olk8-w2 ~]$ grep "k8nfs nfs" /etc/fstab 10.10.0.27:/k8nfs2 /k8nfs nfs rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.27,mo untvers=3,mountport=2048,mountproto=udp,local_lock=none,addr=10.10.0.27 MOUNT ON ODD NODE [opc@olk8-w3 ~]$ grep "k8nfs nfs" /etc/fstab 10.10.0.21:/k8nfs /k8nfs nfs rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.0.21,mountvers=3, mountport=2048,mountproto=udp,local_lock=none,addr=10.10.0.21 - ドメイン・マウントをNFSレプリカNFS2にコピーします(これは、スナップショットまたは直接sftp/セキュア・コピーを介して実行できます)。
たとえば、ドメインがNFS1によってホストされた/k8nfsにデプロイされている場合、ドメインを停止した後、NFS1の/k8nfsにあるデータをNFS2の/k8nfs2にセキュア・コピーします:
$ cd /k8nfs $ scp -R * user@[NFS2]:/k8nfs2 - NFS1の奇数ノードとNFS2の偶数ノードにラベルを付けます。
たとえば、NFS1の場合はdiskgroup=dg1、NFS2の場合はdiskgroup=dg2というラベルを追加します:
$ kubectl label nodes olk8-w1 diskgroup=dg1 $ kubectl label nodes olk8-w2 diskgroup=dg2 $ kubectl label nodes olk8-w3 diskgroup=dg1次のコマンドを使用して追加したラベルを検証します:
$ kubectl get nodes --show-labelsサンプル出力:
NAME STATUS ROLES AGE VERSION LABELS olk8-m1 Ready master 10d v1.XX.X beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=olk8-m1,kubernetes.io/os=linux,node-role.kubernetes.io/master= olk8-m2 Ready master 10d v1.XX.X beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=olk8-m2,kubernetes.io/os=linux,node-role.kubernetes.io/master= olk8-m3 Ready master 10d v1.XX.X beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=olk8-m3,kubernetes.io/os=linux,node-role.kubernetes.io/master= olk8-w1 Ready <none> 10d v1.XX.X beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,diskgroup=dg1,kubernetes.io/arch=amd64,kubernetes.io/hostname=olk8-w1,kubernetes.io/os=linux,name=admin olk8-w2 Ready <none> 10d v1.XX.X beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,diskgroup=dg2,kubernetes.io/arch=amd64,kubernetes.io/hostname=olk8-w2,kubernetes.io/os=linux,name=wls1 olk8-w3 Ready <none> 10d v1.XX.X beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,diskgroup=dg1,kubernetes.io/arch=amd64,kubernetes.io/hostname=olk8-w3,kubernetes.io/os=linux,name=wls2 - ドメイン内の適切なセレクタを割り当てるには:
- ドメイン
(domain.yaml)を編集します。 - クラスタに構成されているすべての管理対象サーバーの管理対象サーバー・セクションを変更します(soa_server1およびsoa_server2の例を次に示します):
managedServers: - serverName: soa_server1 serverPod: nodeSelector: diskgroup: dg1 - serverName: soa_server2 serverPod: nodeSelector: diskgroup: dg2 - domain.yamlの変更を適用します:
$ kubectl apply -f domain.yamlノート:
この冗長PV構成が使用されると、ドメイン内のconfigディレクトリの外部に存在するすべての変更は、セカンダリNASマウントに手動でコピー/同期する必要があります。上の図でNFS2を使用している管理対象サーバーは、$DOMAIN_HOME/configディレクトリでファイル/アーティファクトを変更する構成変更のみをレプリケートします。その他の変更は、WebLogicインフラストラクチャによって自動的にコピーされません。たとえば、
earをデプロイし、configディレクトリの外部のアップロードまたはステージ・ディレクトリを指定した場合、earファイルはWebLogicによってコピーされません)。Fileadapter compositesは、ポッドからアクセス可能なマウントに出力ファイルを配置します。異なるOracle SOA Suiteサーバーのファイルの場所のマウント・ポイントとPV/PVCは同じである必要があるため、$DOMAIN_HOMEの場所に使用されるものとは異なります。アダプタ構成では、すべてのサーバー・ポッドからアクセス可能な別の共通共有場所を使用します。$DOMAIN_HOME以外の別の共有場所を使用してください。
たとえば、新しいNFS共有を作成し、必要なPV/PVCを作成して、すべてのサーバー・ポッドで使用できるようにドメインyamlに更新します。
serverPod: volumeMounts: - mountPath: /u01/oracle/user_projects name: weblogic-domain-storage-volume - mountPath: /u01/dev/testing/adapters name: soainfra-adapters-pv-volume volumes: - name: weblogic-domain-storage-volume persistentVolumeClaim: claimName: soainfra-pvc - name: soainfra-adapters-pv-volume persistentVolumeClaim: claimName: soainfra-adapters-pvc
- ドメイン
フロントエンド・アドレスの設定
Oracle SOA Suite (soa_cluster)およびService Bus (osb_cluster)の各クラスタについて、適切なフロントエンド・アドレスを次のように設定します:
-
WebLogicリモート・コンソールにサインインします。
-
「ツリーの編集」→「環境」→「クラスタ」に移動します。
-
クラスタ名をクリックします。
-
「HTTP」タブをクリックします。
-
「フロントエンド・ホスト」およびフロントエンド・ポートの詳細を入力します。
ノート:
ノート: 各クラスタおよび管理サーバーのフロントエンドの詳細を設定します。
GridLinkデータ・ソースのFANの有効化
Kubernetes上のOracle SOA Suiteのデフォルト・デプロイメントのデータ・ソースは、汎用データ・ソースを使用します。12.2以降のデータベースのONS自動登録では、データ・ソースがGridLink (GLDS)に変換されるようにFANを有効にするだけで済みます。これを行うには、WebLogic管理コンソールまたは次のコマンドを使用し、管理サーバーおよび管理対象サーバーを再起動します:
grep -L fan-enabled $domain_home/config/jdbc/*.xml | xargs sed -i "s/<\/jdbc-data-source>/<jdbc-oracle-params><fan-enabled>true<\/fan-enabled><\/jdbc-oracle-params><\/jdbc-data-source>/g"変更が適用されたら、すべてのデータ・ソースがWebLogicリモート・コンソールでGridLinkデータ・ソースとしてマークされていることを確認します。
ASMの構成
自動サービス移行を構成するステップは、オンプレミスの『エンタープライズ・デプロイメント・ガイド』を参照してください。
coredns割当ての構成
ノート:
このステップは、Oracle SOA Suiteデプロイメントに関係なく、corednsを使用するすべてのKubernetesシステムに適用されます。ただし、ワーカー・ノードの作成は設定で暗黙的に行われるため、このコンテキストで適用されます(Oracle SOA Suiteデプロイメント後)。
コントロール・プレーンとマスター・プレーンの両方を生成するように、corednsのレプリカを構成します。リストア操作をコントロール・プレーンで実行すると、ワーカー・ノードが正常に動作しなくなる可能性があります。corednsが完全にワーカー・ノードに配置されている場合、コントロール・プレーンがメンテナンスのために停止されると、コントロール・プレーンが正しく機能しない可能性があります。少なくとも2つのcorednsポッドをコントロール・プレーンに配置し、別の2つのポッドをワーカー・ノードに配置します。corednsフットプリントは低くなっています。
VIRT RES SHR S %CPU %MEM TIME+ COMMAND
146268 41684 29088 S 0.3 0.1 25:44.04 corednsCoreDNSのドキュメントによると、CoreDNSインスタンスに必要なメモリー量は、次の式で(デフォルト設定を使用して)見積もることができます:
MB required (default settings) = (Pods + Services) / 1000 + 54したがって、まず、コントロール・プレーンとワーカー・プレーンの両方でノードにラベルを付けます。
$ kubectl label nodes olk8-m1 area=dnsarea
$ kubectl label nodes olk8-m2 area=dnsarea
$ kubectl label nodes olk8-m3 area=dnsarea
$ kubectl label nodes olk8-w1 area=dnsarea
$ kubectl label nodes olk8-w2 area=dnsarea
$ kubectl label nodes olk8-w3 area=dnsarea次に、トポロジ分散制約を使用するようにcorednsデプロイメントを更新します
ノート:
トポロジ分散制約は、Kubernetes v1.18で開始されるベータ版です最初に、kube-apiサーバーおよびkube-schedulerで機能ゲートを有効にします。次に、ワーカーおよびコントロール・プレーン・ノードにポッドが適切に分散されるように、corednsデプロイメントを変更します。
corednsトポロジ分散構成の詳細は次のとおりです:
更新されたcorednsデプロイメントyamlの例:
$ kubectl get deployment coredns -n kube-system -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "7"
creationTimestamp: "2021-01-15T13:15:05Z"
generation: 8
labels:
area: dnsarea
k8s-app: kube-dns
managedFields:
- apiVersion: apps/v1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:labels:
.: {}
f:k8s-app: {}
f:spec:
f:progressDeadlineSeconds: {}
f:revisionHistoryLimit: {}
f:selector:
f:matchLabels:
.: {}
f:k8s-app: {}
f:strategy:
f:rollingUpdate:
.: {}
f:maxSurge: {}
f:maxUnavailable: {}
f:type: {}
f:template:
f:metadata:
f:labels:
.: {}
f:k8s-app: {}
f:spec:
f:containers:
k:{"name":"coredns"}:
.: {}
f:args: {}
f:image: {}
f:imagePullPolicy: {}
f:livenessProbe:
.: {}
f:failureThreshold: {}
f:httpGet:
.: {}
f:path: {}
f:port: {}
f:scheme: {}
f:initialDelaySeconds: {}
f:periodSeconds: {}
f:successThreshold: {}
f:timeoutSeconds: {}
f:name: {}
f:ports:
.: {}
k:{"containerPort":53,"protocol":"TCP"}:
.: {}
f:containerPort: {}
f:name: {}
f:protocol: {}
k:{"containerPort":53,"protocol":"UDP"}:
.: {}
f:containerPort: {}
f:name: {}
f:protocol: {}
k:{"containerPort":9153,"protocol":"TCP"}:
.: {}
f:containerPort: {}
f:name: {}
f:protocol: {}
f:readinessProbe:
.: {}
f:failureThreshold: {}
f:httpGet:
.: {}
f:path: {}
f:port: {}
f:scheme: {}
f:periodSeconds: {}
f:successThreshold: {}
f:timeoutSeconds: {}
f:resources:
.: {}
f:limits:
.: {}
f:memory: {}
f:requests:
.: {}
f:cpu: {}
f:memory: {}
f:securityContext:
.: {}
f:allowPrivilegeEscalation: {}
f:capabilities:
.: {}
f:add: {}
f:drop: {}
f:readOnlyRootFilesystem: {}
f:terminationMessagePath: {}
f:terminationMessagePolicy: {}
f:volumeMounts:
.: {}
k:{"mountPath":"/etc/coredns"}:
.: {}
f:mountPath: {}
f:name: {}
f:readOnly: {}
f:dnsPolicy: {}
f:nodeSelector:
.: {}
f:kubernetes.io/os: {}
f:priorityClassName: {}
f:restartPolicy: {}
f:schedulerName: {}
f:securityContext: {}
f:serviceAccount: {}
f:serviceAccountName: {}
f:terminationGracePeriodSeconds: {}
f:tolerations: {}
f:volumes:
.: {}
k:{"name":"config-volume"}:
.: {}
f:configMap:
.: {}
f:defaultMode: {}
f:items: {}
f:name: {}
f:name: {}
manager: kubeadm
operation: Update
time: "2021-01-15T13:15:05Z"
- apiVersion: apps/v1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:labels:
f:area: {}
f:spec:
f:replicas: {}
f:template:
f:metadata:
f:annotations:
.: {}
f:kubectl.kubernetes.io/restartedAt: {}
f:labels:
f:foo: {}
f:spec:
f:topologySpreadConstraints:
.: {}
k:{"topologyKey":"area","whenUnsatisfiable":"DoNotSchedule"}:
.: {}
f:labelSelector:
.: {}
f:matchLabels:
.: {}
f:foo: {}
f:maxSkew: {}
f:topologyKey: {}
f:whenUnsatisfiable: {}
manager: kubectl
operation: Update
time: "2021-01-28T16:00:21Z"
- apiVersion: apps/v1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:annotations:
.: {}
f:deployment.kubernetes.io/revision: {}
f:status:
f:availableReplicas: {}
f:conditions:
.: {}
k:{"type":"Available"}:
.: {}
f:lastTransitionTime: {}
f:lastUpdateTime: {}
f:message: {}
f:reason: {}
f:status: {}
f:type: {}
k:{"type":"Progressing"}:
.: {}
f:lastTransitionTime: {}
f:lastUpdateTime: {}
f:message: {}
f:reason: {}
f:status: {}
f:type: {}
f:observedGeneration: {}
f:readyReplicas: {}
f:replicas: {}
f:updatedReplicas: {}
manager: kube-controller-manager
operation: Update
time: "2021-01-28T16:00:39Z"
name: coredns
namespace: kube-system
resourceVersion: "2520507"
selfLink: /apis/apps/v1/namespaces/kube-system/deployments/coredns
uid: 79d24e61-98f4-434f-b682-132625b04c49
spec:
progressDeadlineSeconds: 600
replicas: 4
revisionHistoryLimit: 10
selector:
matchLabels:
k8s-app: kube-dns
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 1
type: RollingUpdate
template:
metadata:
annotations:
kubectl.kubernetes.io/restartedAt: "2021-01-28T15:29:48Z"
creationTimestamp: null
labels:
foo: bar
k8s-app: kube-dns
spec:
containers:
- args:
- -conf
- /etc/coredns/Corefile
image: k8s.gcr.io/coredns:1.6.7
imagePullPolicy: IfNotPresent
livenessProbe:
failureThreshold: 5
httpGet:
path: /health
port: 8080
scheme: HTTP
initialDelaySeconds: 60
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5
name: coredns
ports:
- containerPort: 53
name: dns
protocol: UDP
- containerPort: 53
name: dns-tcp
protocol: TCP
- containerPort: 9153
name: metrics
protocol: TCP
readinessProbe:
failureThreshold: 3
httpGet:
path: /ready
port: 8181
scheme: HTTP
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
resources:
limits:
memory: 170Mi
requests:
cpu: 100m
memory: 70Mi
securityContext:
allowPrivilegeEscalation: false
capabilities:
add:
- NET_BIND_SERVICE
drop:
- all
readOnlyRootFilesystem: true
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /etc/coredns
name: config-volume
readOnly: true
dnsPolicy: Default
nodeSelector:
kubernetes.io/os: linux
priorityClassName: system-cluster-critical
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
serviceAccount: coredns
serviceAccountName: coredns
terminationGracePeriodSeconds: 30
tolerations:
- key: CriticalAddonsOnly
operator: Exists
- effect: NoSchedule
key: node-role.kubernetes.io/master
topologySpreadConstraints:
- labelSelector:
matchLabels:
foo: bar
maxSkew: 1
topologyKey: area
whenUnsatisfiable: DoNotSchedule
volumes:
- configMap:
defaultMode: 420
items:
- key: Corefile
path: Corefile
name: coredns
name: config-volume
status:
availableReplicas: 4
conditions:
- lastTransitionTime: "2021-01-21T19:08:12Z"
lastUpdateTime: "2021-01-21T19:08:12Z"
message: Deployment has minimum availability.
reason: MinimumReplicasAvailable
status: "True"
type: Available
- lastTransitionTime: "2021-01-28T15:29:48Z"
lastUpdateTime: "2021-01-28T16:00:39Z"
message: ReplicaSet "coredns-84b49c57fd" has successfully progressed.
reason: NewReplicaSetAvailable
status: "True"
type: Progressing
observedGeneration: 8
readyReplicas: 4
replicas: 4
updatedReplicas: 4ラベルおよび分散トポロジの変更は次のとおりです:
labels:
foo: bar
k8s-app: kube-dns
topologySpreadConstraints:
- labelSelector:
matchLabels:
foo: bar
maxSkew: 1
topologyKey: area
whenUnsatisfiable: DoNotScheduleこれにより、マスター・ノードとワーカー・ノード間での均等分散が保証されるため、コントロール・プレーンがリストアされると、ワーカー・ポッドは問題なく続行され、その逆も同様です。
結果として得られるcoredns分散の例:
$ kubectl get pods -A -o wide | grep coredns
kube-system coredns-84b49c57fd-4fz4g 1/1 Running 0 166m 10.244.1.20 olk8-m2 <none> <none>
kube-system coredns-84b49c57fd-5mrkw 1/1 Running 0 165m 10.244.4.76 olk8-w2 <none> <none>
kube-system coredns-84b49c57fd-5zm88 1/1 Running 0 165m 10.244.2.17 olk8-m3 <none> <none>
kube-system coredns-84b49c57fd-nqlwb 1/1 Running 0 166m 10.244.4.75 olk8-w2 <none> <none>サーバーのポッドの有効性プローブの調整
デフォルトでは、有効性プローブは45秒ごとに有効性を確認するように構成されており、停止シナリオでは使用できなくなったバックエンド・ポッドにリクエストがルーティングされる可能性があります。ハード・ノードの障害時にポッドがより迅速に停止とマークされるように、有効性プローブの値を調整することをお勧めします。プローブをより頻繁に実行するよう構成するには、ドメインを編集して、serverPods.livenessProbeの値を次のように変更します:
livenessProbe:
failureThreshold: 1
initialDelaySeconds: 60
periodSeconds: 40
successThreshold: 1
timeoutSeconds: 5有効性プローブのカスタマイズ方法の詳細は、WebLogic Kubernetes Operatorのドキュメントを参照してください。