Kubernetes Engine for Oracle Private Cloud Applianceは、Oracle VMインフラストラクチャおよびKubernetesコンポーネントのプロビジョニングを自動化して、Oracle Private Cloud Applianceの統合ソリューションを提供します。 Oracle Private Cloud Appliance管理者は、Kubernetesクラスタを定義および構築し、Kubernetes管理者のニーズに応じて後でスケール・アップまたはスケール・ダウンします。
Oracle Private Cloud Applianceは、Kubernetesアプリケーション・コンテナのデプロイメント、スケーリングおよび管理を簡単に自動化します。 Kubernetes Engine for Oracle Private Cloud Applianceを使用するには、次のステップに従います。
この項では、Oracle Private Cloud Appliance上のKubernetesのガイドラインおよび制限事項について説明します。
Oracle Private Cloud Applianceサービスを使用して構築されたKubernetesクラスタには、常に3つのマスター・ノードとロード・バランサが含まれます。
Kubernetesクラスタには、ロード・バランサの静的な浮動IPv4アドレスが必要です(仮想マシンがクラスタ・ノードのDHCPアドレスと静的アドレスのどちらを使用するかは関係ありません)。
IPv4クラスタのみがサポートされています。
静的アドレスを持つネットワークをVM外部ネットワークに使用する場合は、仮想マシンで使用されるホスト名を解決できる必要があります。
Oracle Private Cloud Applianceごとに最大255のKubernetesクラスタを作成できます。
Kubernetesクラスタごとに最大255個のノード・プールを作成できます。
Oracle Private Cloud Appliance管理者は、Kubernetesクラスタをプロビジョニングする前に、Virtual Routing Redundancy Protocol (VRRP)と、Kubernetesクラスタをホストする外部ネットワークですでに使用されているかどうかを理解する必要があります。 詳細は、「仮想ルーティング冗長プロトコル」を参照してください。
Kubernetesクラスタを実行しているOracle Private Cloud Applianceコンピュート・ノードをプロビジョニング解除する場合は、この手順に従います: 第7.11項、「コンピュート・ノードのプロビジョニング解除および置換」
ミラー化されたストレージ・プールは、Oracle Private Cloud Appliance上のKubernetesで優先されるZFS構成です。
Kubernetesクラスタ構成で変更(CRUD)を実行した後、Kubernetesクラスタ構成の手動バックアップを実行して、一貫性バックアップを確保します。
定義後のKubernetesクラスタの起動にかかる時間は、Kubernetesクラスタのサイズや、クラスタの構築中のOracle VM管理操作の使用状況によって大きく異なります。 Oracle VMがKubernetesクラスタの起動と同時に頻繁に使用されない場合、3つのマスター・ノードと3つのワーカー・ノードを構築するデフォルトのKubernetesクラスタには約45分かかります。 追加(または減算された各ワーカー・ノード)ごとに、Oracle VMの管理使用状況および重複するクラスタ操作に応じて、ビルド時間を約5分調整します。
また、Oracle Private Cloud Appliance内のコンピュート・ノードが多いほど、ネットワーク/VLANインタフェースが作成され、すべてのノードに追加またはすべてのノードから削除されるため、起動および停止のタイミングが長くなるため、クラスタの構築にかかる時間が長くなります。
この項では、Oracle Private Cloud Applianceでクラスタ環境を準備する方法について説明します。 まず、次に示すように、Kubernetes Oracle VM Virtual Applianceをダウンロードしてから、Kubernetes用のK8s_Privateネットワークを作成します。
仮想アプライアンス・テンプレートは、Oracle VM環境の他の仮想アプライアンスと同様に動作します。 Kubernetes仮想アプライアンスには、仮想マシンごとに50 GBの領域が必要です。 仮想アプライアンスをダウンロードして1つ以上のOracle VMリポジトリに追加すると、それを使用してKubernetesクラスタを構築できます。
K8s_Privateネットワークは、クラスタが内部的に通信する方法を提供するために必要です。 構成後は、 K8s_Privateネットワークの管理を最小限に抑える必要があります。
Kubernetes Engine for Oracle Private Cloud Applianceのダウンロード
Kubernetes Engine for Oracle Private Cloud ApplianceをOracle Software Delivery Cloudからアクセス可能なHTTPサーバーにダウンロードします。 「Kubernetes Engine」を検索してファイルを見つけます。
ヒント単純なHTTPサーバーをステージングするには、https://docs.python.org/2/library/simplehttpserver.htmlを参照してください。 たとえば、次のコマンドを発行して、仮想アプライアンスをダウンロードしたディレクトリに移動します:
python -m SimpleHTTPServer 8000 The URL in the next step will be http://<your client IP address>:8000/<the downloaded filename> -------------------------------
次のステップで次のURLを入力します:
http://<your-client-IP-address>:8000/<the-downloaded-filename>
Oracle VM Manager 「リポジトリ」タブから、目的のリポジトリを選択し、Virtual Appliancesを選択します。
仮想アプライアンスのインポートをクリックして、次の手順を実行します:
ダウンロードした仮想アプライアンスのURLを入力します。
Kubernetes Oracle VM Virtual Applianceはここにあります: (入力URL)
プロキシ・サーバーのホスト名またはIPアドレスを入力します。
Oracle VMによって仮想アプライアンスの名前が変更された場合(文字が追加されている可能性があります)、名前を
pca-k8s-1-0-0.ovaに戻します。Kubernetesクラスタ・ノードを構築するリポジトリごとに繰り返します。
K8s_Privateネットワークの作成
SSHおよびスーパーユーザー権限のあるアカウントを使用して、アクティブ管理ノードにログインします。
ノートデフォルトの
rootパスワードは、Welcome1です。 セキュリティ上の理由により、ただちに新しいパスワードを設定する必要があります。# ssh root@10.100.1.101 root@10.100.1.101's password: root@ovcamn05r1 ~]#
Oracle Private Cloud Applianceコマンドライン・インタフェースを起動します。
# pca-admin Welcome to PCA! Release: 2.4.3 PCA>
プライベート・ネットワークを作成します。
K8s_Privateネットワークで使用する内部ネットワークの名前を指定します。PCA> create network K8S_Private rack_internal_network
Kubernetesクラスタに使用される各テナント・グループにプライベート・ネットワークを追加します。
PCA> add network-to-tenant-group K8S_Private
tenant_group1ノートOracle Private Cloud Applianceで使用可能なコンピュート・ノードの数によっては、
add network-to-tenant-groupコマンドに10分以上かかる場合があります。 クラスタの作成は、K8S_Privateネットワークがすべてのコンピュート・ノードに割り当てられた後にのみ実行する必要があります。ネットワークが作成されたことを確認します。
PCA> list network
このセクションでは、DHCPネットワーク上にデフォルトの3つのマスター・ノードと3つのワーカー・ノードを持つKubernetesクラスタ定義を作成する方法について説明します。 コマンド・リファレンス情報は、第4.2.14項、「create kube-cluster」を参照してください。
DHCPネットワークでのKubernetesクラスタの作成
Oracle Private Cloud Applianceコマンドライン・インタフェースから、クラスタの名前、サーバー・プール、外部ネットワーク、ロード・バランサのIPアドレス(静的IPv4アドレス)、ストレージ・リポジトリおよび仮想アプライアンス名(オプション)を指定します。
PCA> create kube-cluster cluster-1 Rack1-ServerPool vm_public_lan load_balancer_ipaddress Rack1-Repository Kubernetes cluster configuration (cluster-1) created Status: Success
ノートクラスタを正常に作成するには、
vm_public_lanまたはクラスタに使用する外部ネットワークが稼働しており、アクセス可能である必要があります。 このネットワークは、使用するストレージ・プール内のすべてのコンピュート・ノードに割り当てる必要があります。そうしないと、クラスタは起動しません。クラスタ定義が正しく作成されたことを確認してください。
PCA> show kube-cluster cluster-1 ---------------------------------------- Cluster cluster-1 Tenant_Group Rack1_ServerPool Tenant_Group_ID 0004fb000020000001398d8312a2bc3b State CONFIGURED Sub_State VALID Ops_Required None Load_Balancer 100.80.151.119 External_Network vm_public_vlan External_Network_ID 1096679b1e Repository Rack1-Repository Repository_ID 0004fb000030000005398d83dd67126791 Assembly PCA_K8s_va.ova Assembly_ID 11af134854_PCA_K8s_OVM_OL71 Masters 3 Workers 3 ---------------------------------------- Status: Success
クラスタ定義にワーカー・ノードを追加するには、クラスタ名、ワーカー・プール内のノード数またはワーカー・プール内のノード名を指定します。 第4.2.49項、「set kube-worker-pool」を参照してください。
クラスタを起動します。 このステップでは、先ほど作成したクラスタ構成からクラスタを構築します。 クラスタ定義のサイズによっては、このプロセスに30分から数時間かかる場合があります。 マスター・ノード・プールは3つのマスター・ノードで定義されており、変更できません。 ただし、ワーカー・ノードはDHCPクラスタ定義に追加できます。
PCA> start kube-cluster cluster-1
show kube-clusterコマンドを使用して、ビルドの進行状況に従います。PCA> show kube-cluster cluster-1 ---------------------------------------- Cluster cluster-1 Tenant_Group Rack1_ServerPool Tenant_Group_ID 0004fb000020000001398d8312a2bc3b State AVAILABLE Sub_State None Ops_Required None Load_Balancer 172.16.0.157 Vrrp_ID 236 External_Network default_external Cluster_Network_Type dhcp Gateway None Netmask None Name_Servers None Search_Domains None Repository Rack2-Repository Assembly PCA_K8s_va.ova Masters 3 Workers 3 Cluster_Start_Time 2020-06-14 06:11:32.765239 Cluster_Stop_Time None Job_ID None Job_State None Error_Code None Error_Message None ---------------------------------------- Status: Success
クラスタの状態の詳細は、第4.2.52項、「start kube-cluster」を参照してください。
クラスタが起動したら、クラスタのノード・プール情報を収集します。
この情報を保存します。この情報を使用して、後でクラスタをKubernetesに渡します。
PCA> list node-pool --filter-column=Cluster --filter=cluster-1 Cluster Node_Pool Tenant_Group CPUs Memory Nodes ------- --------- ------------ ---- ------ ----- cluster-1 master Rack1_ServerPool 4 16384 3 cluster-1 worker Rack1_ServerPool 2 8192 2 ---------------- 2 rows displayed Status: Success
クラスタがAVAILABLE状態になったら、手動バックアップを実行して新しいクラスタ状態を取得することを検討してください。 第4.2.8項、「backup」を参照してください。
この項では、静的ネットワーク上に3つのマスター・ノートおよび1つのワーカー・ノードを持つKubernetesクラスタを作成する方法について説明します。
静的ネットワークでのKubernetesクラスタの作成
Oracle Private Cloud Applianceコマンドライン・インタフェースから、クラスタの名前、サーバー・プール、外部ネットワーク、ロード・バランサのIPアドレス、ストレージ・リポジトリおよび仮想アプライアンス(オプション)を指定します。
PCA> create kube-cluster cluster-2 Rack1-ServerPool vm_public_lan load-balancer_ipaddress Rack1-Repository Kubernetes cluster configuration (cluster-2) created Status: Success
クラスタのネットワーク・タイプを静的に設定します。 クラスタ名、ネットワーク・タイプ、ネットマスクおよびゲートウェイを指定します。 第4.2.47項、「set kube-network」を参照してください。
ノートクラスタを正常に作成するには、クラスタに使用するネットワークが起動しており、アクセス可能である必要があります。 このネットワークは、使用するストレージ・プール内のすべてのコンピュート・ノードに割り当てる必要があります。そうしないと、クラスタは起動しません。
PCA> set kube-network cluster-2 static netmask_IP gateway_IP
クラスタのDNSサーバーを設定します。 クラスタ名、DNSネーム・サーバーaddress(es)および検索ドメインを指定します。 第4.2.44項、「set kube-dns」を参照してください。
PCA> set kube-dns dns_IP_1,dns_IP_2 mycompany.com
クラスタ定義が正しく作成されたことを確認してください。
PCA> show kube-cluster cluster-2 ---------------------------------------- Cluster Static Tenant_Group Rack1_ServerPool State AVAILABLE Sub_State None Ops_Required None Load_Balancer 172.16.0.220 Vrrp_ID 152 External_Network default_external Cluster_Network_Type static Gateway 172.16.0.1 Netmask 255.254.0.0 Name_Servers 144.20.190.70 Search_Domains ie.company.com,us.voip.companyus.com Repository Rack1-Repository Assembly OVM_OL7U7_x86_64_PVHVM.ova Masters 3 Workers 3 Cluster_Start_Time 2020-07-06 23:53:17.717562 Cluster_Stop_Time None Job_ID None Job_State None Error_Code None Error_Message None ---------------------------------------- Status: Success
クラスタ定義にワーカー・ノードを追加するには、クラスタ名を指定してから、ワーカー・プールに必要なノードの名前をリストします。 第4.2.49項、「set kube-worker-pool」を参照してください。
PCA> set kube-worker-pool cluster-2 worker-node-vm7 worker-node-vm8 worker-node9
マスター・プールをクラスタ定義に追加するには、クラスタ名を指定し、プライマリ・マスター・ノードとその名前およびIPアドレスをリストしてから、マスター・プールに必要な他のノードの名前をリストします。 第4.2.46項、「set kube-master-pool」を参照してください。
PCA> set kube-master-pool demo-cluster cluster-master-0,192.168.0.10 cluster-master-1 cluster-master-2
クラスタを起動します。 このステップでは、先ほど作成したクラスタ構成からクラスタを構築します。 クラスタ定義のサイズによっては、このプロセスに30分から数時間かかる場合があります。
PCA> start kube-cluster cluster-2 Status: Success
show kube-clusterコマンドを使用して、ビルドの進行状況に従います。PCA> show kube-cluster cluster-2 <need example>
クラスタの状態の詳細は、第4.2.52項、「start kube-cluster」を参照してください。
クラスタが起動したら、クラスタのノード・プール情報を収集します。
この情報を保存します。この情報を使用して、後でクラスタをKubernetesに渡します。
PCA> list node-pool --filter-column=Cluster --filter=cluster-2 Cluster Node_Pool Tenant_Group CPUs Memory Nodes ------- --------- ------------ ---- ------ ----- cluster-2 master Rack1_ServerPool 4 16384 3 cluster-2 worker Rack1_ServerPool 2 8192 2 ---------------- 2 rows displayed Status: Success
手動バックアップを実行して新しいクラスタ状態を取得することを検討してください。 第4.2.8項、「backup」を参照してください。
この項では、start kube-cluster操作中にKubernetesクラスタとともにデプロイされるKubernetesダッシュボードの使用方法について説明します。
Kubernetesダッシュボードの使用
ローカル・マシンに
kubectlをインストールします。kubernetes.ioから「kubectlのインストールおよび設定」への指示に従います。
クラスタ構成をマスター・マシンからローカル・マシンにコピーします。
# scp root@<
load-balancer-ip>:~/.kube/config ~/.kube/configローカル・マシンに.
kubeサブディレクトリを作成します。# mkdir -p $HOME/.kube
Kubernetes構成ファイルのロケーションを設定します。
# export KUBECONFIG=~/.kube/config
クラスタ内のノードが稼働していることを確認します。
# kubectl get nodes
dashboard-rbac.yamlを使用して、Kubernetesダッシュボードのデフォルトのユーザー・ロールを作成します。# kubectl apply -f dashboard-rbac.yaml
Kubernetesダッシュボードの詳細は、https://docs.oracle.com/en/operating-systems/olcne/orchestration/dashboard.htmlを参照してください。
kubectlの詳細は、https://docs.oracle.com/en/operating-systems/olcne/orchestration/kubectl-setup-master.htmlを参照してください。Kubernetesダッシュボードのログイン・トークンを作成します。
「Kubernetesダッシュボードgithubサイト」の「Bearerトークンの取得」の指示に従います。
ホストでプロキシを起動します。
# kubectl proxy
Kubernetesダッシュボードを開きます。
http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#/login
ダッシュボードにクラスタが表示されます。 これで、Kubernetes管理者は、他のKubernetesクラスタと同様に、ダッシュボードを使用してクラスタを管理できます。 詳細は、「Oracle Linux Cloudネイティブ・コンテナ・オーケストレーションのドキュメント」を参照してください。
必要に応じて、ワーカー・ノードのインターネット・アクセスを構成できます。 これにより、企業ネットワーク外の依存関係を持つアプリケーションのデプロイメントが容易になります。
この項では、既存のクラスタに対して行う可能性のある一般的な変更について説明します。 クラスタに変更を加えたら、Oracle Private Cloud Applianceの手動バックアップを実行して新しい構成を保存します。 第4.2.8項、「backup」を参照してください。
タスク | 説明 |
|---|---|
クラスタを停止します | PCA> stop kube-cluster
第4.2.54項、「stop kube-cluster」を参照してください。 |
ノード・プールの追加 | PCA> add node-pool
第4.2.6項、「add node-pool」を参照してください。 |
ノード・プールの削除 | PCA> remove node-pool 第4.2.39項、「remove node-pool」を参照してください。 |
ノード・プール・ノードの追加 | PCA> add node-pool-node 第4.2.7項、「add node-pool-node」を参照してください。 |
ノード・プール・ノードの削除 | PCA> remove node-pool-node 第4.2.40項、「remove node-pool-node」を参照してください。 |
マスターまたはワーカーのデフォルト・ノード・プールの一部であるVMのプロファイルの変更 | PCA> set kube-vm-shape
第4.2.48項、「set kube-vm-shape」を参照してください。 |
クラスタを停止するには、ベース・マスター・ノード・プールおよびワーカー・ノード・プール以外のクラスタ・ノード・プールからすべてのノードを空にし、空になったら余分なノード・プールを削除する必要があります。 この項では、実行中のクラスタを停止してから構成情報を削除する順序について説明します。
クラスタの停止後にクラスタ構成を削除する必要はありません。 停止したクラスタには、クラスタの停止時からのマスター・ノード・プールおよびワーカー・ノード・プールに関する情報が保持されます。 停止したクラスタ内のアドレスと競合する他のクラスタが構築されていない場合、クラスタ構成を使用して、元の状態にリセットされた内容でクラスタを再度起動できます。
クラスタの停止および構成データの削除
Oracle Private Cloud Applianceコマンドライン・インタフェースから、ワーカー・ノードを削除します。
PCA> remove node-pool-node
MyClusternode-pool-0hostnameノード・プールが空になるまで、ノード・プール内のワーカー・ノードごとに繰り返します。
ノード・プールを削除します。
PCA> remove node-pool
MyClusternode-pool-0クラスタが空になるまで、クラスタ内の各ノード・プールに対して繰り返します。
非マスター・ノード・プールと非ワーカー・ノード・プールが削除されたら、クラスタを停止します。
PCA> stop kube-cluster
MyClusterノート--forceオプションは、stop kube-clusterコマンドで使用できます。 このオプションでは、ノード・プールに関係なくすべてのワーカーを停止し、ノード・プール(マスターおよびワーカー以外)を削除して、クラスタを停止状態のままにします。クラスタの削除
PCA> delete kube-cluster
MyCluster手動バックアップを実行して新しいクラスタ状態を取得することを検討してください。 第4.2.8項、「backup」を参照してください。
Kubernetesクラスタ・ステータスには、Kubernetesクラスタで使用される仮想マシンのステータス、およびKubernetes自体の2つの部分があります。
Kubernetesクラスタをホストする重要なマシンを監視するには、Oracle Private Cloud Applianceコマンドラインを使用してそれらの仮想マシンのリストを取得します。 リストが表示されたら、Oracle VMにログインして、各VM、その実行状態およびその他の関連情報をより深く調べます。
Oracle Private Cloud Appliance管理者はOracle VMヘルスにアクセスできますが、Kubernetesランタイム・ヘルスにはアクセスできません。 Kubernetesのステータスを表示するには、Kubernetes管理者は第2.13.5項、「Kubernetesダッシュボードの使用」および様々な
kubectlコマンドを使用する必要があります。 「kubectlの概要」を参照してください。
Kubernetes仮想マシンのディスク領域のサイズ変更
Oracle VM Managerにログインします。
詳細は、第5.2項、「Oracle VM Manager Web UIへのログイン」を参照してください。
変更するKubernetes仮想マシンを選択し、編集をクリックして、ディスク・タブを選択し、必要なディスク・サイズを編集します。
詳細は、「仮想マシンの編集」を参照してください
編集したKubernetes仮想マシンにログインし、ディスク領域の量を確認します。
[root@dhcp1-m-1 ~]# df -kh Filesystem Size Used Avail Use% Mounted on devtmpfs 16G 0 16G 0% /dev tmpfs 16G 0 16G 0% /dev/shm tmpfs 16G 18M 16G 1% /run tmpfs 16G 0 16G 0% /sys/fs/cgroup /dev/xvda3 46G 5.8G 39G 14% / /dev/xvda1 497M 90M 407M 19% /bootこの例では、
/dev/xvda3のサイズを46Gから496Gに増やす方法を示します。fdiskを実行してディスク領域をパーティション化します。[root@dhcp1-m-1 ~]# fdisk /dev/xvda Welcome to fdisk (util-linux 2.23.2). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Command (m for help): d Partition number (1-3, default 3): 3 Partition 3 is deleted Command (m for help): n Partition type: p primary (2 primary, 0 extended, 2 free) e extended Select (default p): p Partition number (3,4, default 3): First sector (9414656-1048575999, default 9414656): Using default value 9414656 Last sector, +sectors or +size{K,M,G} (9414656-1048575999, default 1048575999): Using default value 1048575999 Partition 3 of type Linux and of size 495.5 GiB is set Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. WARNING: Re-reading the partition table failed with error 16: Device or resource busy. The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) Syncing disks.partprobeコマンドを使用して、カーネルに新しいパーティションを認識させます。[root@dhcp1-m-1 ~]# partprobe
btrfsコマンドを使用して、パーティションのサイズをmaxに変更します。[root@dhcp1-m-1 ~]# btrfs filesystem resize max / Resize '/' of 'max'
新しいパーティションのサイズを確認します。
[root@dhcp1-m-1 ~]# df -kh Filesystem Size Used Avail Use% Mounted on devtmpfs 16G 0 16G 0% /dev tmpfs 16G 0 16G 0% /dev/shm tmpfs 16G 18M 16G 1% /run tmpfs 16G 0 16G 0% /sys/fs/cgroup /dev/xvda3 496G 5.7G 489G 2% / /dev/xvda1 497M 90M 407M 19% /boot
Oracle Private Cloud Appliance管理者がワーカー・ノードを追加するか、マスター・ノードを再度追加すると、個々のノードは、Oracle Linuxバージョン、Kubernetesバージョン、およびKubernetes仮想アプライアンスの一部であったデフォルト設定で使用可能になります。
Kubernetes管理者は、次を使用して新しいノードを更新する必要があります:
更新された
rootパスワードまたはパスワードなしの認可を使用するための変更CRI-Oが新しいコンテナ・イメージを取得するために使用するプロキシを更新
Oracle Linux配布コンポーネントを更新する可能性があります
これらの操作の多くは、新しいノードが追加されたときに適用されるAnsibleプレイブックを使用して効率的に実行できます。
Kubernetes仮想アプライアンスは、Oracle Linux 7更新8に基づいています。 管理者は、実行後にこれらのイメージを更新でき、新しいノードには元のOracle Linux 7更新8があることに注意してください。
Kubernetes仮想アプライアンスはOracle Linuxを使用するため、管理者はhttps://docs.oracle.com/en/operating-systems/oracle-linux/7/relnotes7.8/ol7-preface.htmlの手順に従って、選択した更新をランタイム・ノードに配置できます(セキュリティ更新のためのカーネルまたは個々のパッケージの更新など)。 管理者は、ランタイム・ノードでできるかぎり少ない数の更新を実行し、Kubernetes仮想アプライアンスを保守するための具体的な提案について、My Oracle Supportノートを介してOracleガイダンスを探す必要があります。