このコンテンツを正しく表示するには、JavaScriptが有効になっている必要があります

このドキュメントで説明するソフトウェアは、サポートされなくなったか、Extended Support期間中です。
現在サポートされているリリースにアップグレードすることをお薦めします。

第3章 Kubernetesと使用する高可用性Oracle Linux Container Servicesのインストール

この章では、Oracle Linux 7ホストで可用性が高まるように構成されたマスター・ノードを使用してKubernetesクラスタをインストールするのに必要なステップについて説明します。

3.1 概要

Kubernetesは、よりスケーラブルで回復可能なサービスを提供するために、必要なマスター・ノードの複数のレプリカとともにデプロイでき、これらのレプリカへの自動フェイルオーバーを実現します。

kubeadmパッケージには、Kubernetesクラスタのデプロイメントを簡素化するように設計されたツールであるkubeadmユーティリティが用意されています。多くのユーザーは、このツールを直接アップストリームのドキュメントと一緒に使用することで、構成の柔軟性を最大限に高めることができます。

オラクル社はkubeadm-ha-setupツールを追加のkubeadm-ha-setupパッケージで提供しているため、新規ユーザーは、ベアメタル、仮想マシンまたは外部のクラウド上でホストされているかどうかに関係なく、Kubernetesの高可用性デプロイメントをより簡単にインストールおよび構成できます。このツールにより、基本的なパッケージ要件が満たされているかどうかの確認、プロキシとファイアウォールの要件の設定、ネットワーキングの構成、およびKubernetes環境の高可用性マスター・クラスタ構成の初期化が処理されます。このツールではkubeadmユーティリティを使用しますが、新しいユーザーが最小限の労力で開始するために役立つ数多くの追加構成ステップを処理します。

ここに示す手順は、Kubernetesを初めて使用し、提供されているkubeadm-ha-setupツールを使用してクラスタをデプロイすることを前提としています。このツールはオラクル社で開発およびテストされ、このツールを使用したデプロイメントは完全にサポートされます。代替構成およびデプロイメント・メカニズムは、オラクル社によってテストされていません。

重要

高可用性クラスタは、1つのマスター・ノード障害に対するレジリエンスを備えています。複数のマスター・ノードに障害が発生した場合、データ損失を回避するために、マスター・クラスタをバックアップ・ファイルからリストアする必要があります。

3.2 要件

可用性が高まるように構成されたKubernetesには、マスター・クラスタ内の3つのノードおよび少なくとも1つのワーカー・ノードが必要です。

3つのマスター・ノードを作成すると、分散キー・ストア(etcd)により、これらのマスター・ノード間における構成データのレプリケーションが確実化されるため、高可用性クラスタは、単一ノード障害についてデータや稼働時間を損失することなく回復可能となります。

各マスター・ノードを異なるKubernetesゾーンに配置すると、マスター・クラスタ内でゾーン障害が発生した場合にクラスタの可用性を保護できます。

次の各項では、Oracle Linux 7ホストに高可用性を備えたKubernetesクラスタをインストールおよび構成するために満たす必要がある様々な要件について説明します。

3.2.1 YumまたはULNチャネル・サブスクリプション

Kubernetesを使用するために必要なすべてのパッケージをインストールするには、正しいyumリポジトリまたはUnbreakable Linuxネットワーク(ULN)チャネルをサブスクライブしていることを確認する必要があります。

システムがULNで登録されている場合は、ol7_x86_64_addonsチャネルを有効にします。

Oracle Linux yumサーバーを使用する場合は、デプロイメント内の各システムでol7_addonsリポジトリを有効にします。これは、yum-config-managerを使用して簡単に実行できます。

# yum-config-manager --enable ol7_addons

ol7_x86_64_addonsチャネルの詳細は、Oracle® Linux: Unbreakable Linux Networkユーザーズ・ガイドfor Oracle Linux 6 and Oracle Linux 7を参照してください。

重要

オラクル社は、ol7_preview、ol7_developerまたはol7_developer_EPELリポジトリが有効になっているシステム、またはKubernetesが実行されるシステムにこれらのリポジトリのソフトウェアが現在インストールされているシステムで、Kubernetesをサポートしていません。このドキュメントの指示に従っても、これらのリポジトリまたはチャネルが有効化されている場合や、これらのチャネルまたはリポジトリのソフトウェアがシステムにインストールされている場合は、プラットフォームがサポートされないことがあります。

3.2.2 Unbreakable Enterprise Kernelをアップグレードするための要件

Kubernetesと使用するOracle Linux Container Services 1.1.12以降のバージョンでは、Unbreakable Enterprise Kernelリリース5 (UEK R5)を使用するようにシステムを構成し、このカーネルを使用してシステムをブートする必要があります。UEK R4またはRed Hat Compatible Kernel (RHCK)のいずれかを使用している場合は、UEK R5をインストールできるようにYumを構成する必要があります。

使用中のシステムがUnbreakable Linux Network (ULN)で登録されている場合、ol7_x86_64_UEKR4チャネルへのアクセスを無効にし、ol7_x86_64_UEKR5チャネルへのアクセスを有効にします。

Oracle Linux yumサーバーを使用する場合は、ol7_UEKR4リポジトリを無効にし、ol7_UEKR5リポジトリを有効にします。yum-utilsパッケージがインストールされている場合は、yum-config-managerを使用して簡単にこれを実行できます。
```
# yum-config-manager --disable ol7_UEKR4
# yum-config-manager --enable ol7_UEKR5
```
次のコマンドを実行して、システムをUEK R5にアップグレードします。
```
# yum update
```
UEK R5をデフォルトのブート・カーネルにする方法の詳細は、Oracle® Linux 7: 管理者ガイドを参照してください。
UEK R5カーネルがデフォルトのブート・カーネルでない場合はこれを選択して、システムを再起動します。
```
# systemctl reboot
```

3.2.3 リソース要件

クラスタ内の各ノードでは、kubeadmの使用およびkubectlを使用してプロビジョニングされるその他のアプリケーションの使用を容易にするために、2 GB以上のRAMおよび2つ以上のCPUが必要です。

また、各ノードに一意のホスト名、MACアドレスおよび製品UUIDがあることも確認します。これは、クラスタ内の各ノードの識別および追跡のために、Kubernetesによってこの情報が使用されるためです。次を使用して、各ホストの製品UUIDを確認できます。

# dmidecode -s system-uuid

各ノードの/var/lib/kubeletディレクトリまたはボリュームで、5 GB以上の空き領域が使用可能である必要があります。基礎となるDockerエンジンでは、各ノードの/var/lib/dockerディレクトリまたはボリュームで、さらに5 GBの空き領域が使用可能である必要があります。

3.2.4 Dockerエンジンの要件

Kubernetesは、複数のシステムにデプロイされたコンテナ化プラットフォームで実行中のコンテナを管理するために使用されます。Oracle Linuxでは、Kubernetesは現在、Dockerコンテナ化プラットフォームと組み合せて使用されている場合にのみサポートされます。そのため、デプロイメントの各システムにDockerエンジンがインストールされ、実行する準備ができている必要があります。Kubernetesと使用するOracle Linux Container Servicesのサポートは、Oracle Linux yumサーバー上のol7_addonsリポジトリおよびULN上のol7_x86_64_addonsチャネルで使用可能な、最新のOracle Container Runtime for Dockerバージョンでの使用に限定されます。

ol7_previewリポジトリを有効にすると、Oracle Container Runtime for Dockerのプレビュー・バージョンをインストールでき、インストールはオラクル社によってサポートされなくなります。ol7_previewリポジトリからDockerのバージョンをすでにインストールしている場合は、インストールを続行する前に、リポジトリを無効にしてこのバージョンをアンインストールする必要があります。

クラスタ内のすべてのノードでDockerエンジンをインストールします。

# yum install docker-engine

systemdでDockerサービスを有効化して以降の再起動で開始するようにし、kubeadm-setup.shツールを実行する前にこのサービスを起動する必要あります。

# systemctl enable docker
# systemctl start docker

Dockerエンジンのインストールおよび実行の詳細は、Oracle® Linux: Oracle Container Runtime for Dockerユーザー・ガイドを参照してください。

3.2.5 Oracle Container Registryの要件

kubeadm-ha-setupツールによってデプロイされたイメージは、Oracle Container Registryでホストされます。ツールで必要なコンポーネントをインストールできるようにするには、次のステップを実行する必要があります。

シングル・サインオン資格証明を使用して、Oracle Container RegistryのWebサイト(https://container-registry.oracle.com)にログインします。
Webインタフェースを使用してContainer Servicesビジネスエリアに移動し、デプロイする予定のOracleソフトウェア・イメージのOracle標準の条件および制約を受け入れます。このビジネスエリア内の既存のすべてのリポジトリに適用される、グローバル契約を受け入れることができます。将来、このビジネスエリアに新しいリポジトリが追加された場合、アップグレードを実行する前に、これらの条件を再度受け入れることが必要になる場合があります。
クラスタ内のノードとして使用される各システムがhttps://container-registry.oracle.comにアクセスし、docker loginコマンドを使用して、Webインタフェースへのログインに使用したものと同じ資格証明によってOracle Container Registryに対して認証できることを確認します。
```
# docker login container-registry.oracle.com
```
このコマンドにより、ユーザー名とパスワードの入力を求められます。

Oracle Container Registryの詳細は、Oracle® Linux: Oracle Container Runtime for Dockerユーザー・ガイドを参照してください。

3.2.5.1 Oracle Container Registryミラーの使用方法

Oracle Container Registryミラー・サーバーのいずれかを使用して、Kubernetesと使用するOracle Linux Container Servicesを設定する正しいイメージを取得することもできます。Oracle Container Registryミラー・サーバーは、Oracle Cloud Infrastructureで使用されるものと同じデータ・センター内に配置されます。Oracle Container Registryミラー・サーバーの詳細は、Oracle® Linux: Oracle Container Runtime for Dockerユーザー・ガイドを参照してください。

代替のOracle Container Registryミラー・サーバーを使用するステップは、次のとおりです。

シングル・サインオン資格証明を使用して、引き続きOracle Container RegistryのWebサイト(https://container-registry.oracle.com)にログインし、Webインタフェースを使用して、Oracle標準の条件および制約を受け入れる必要があります。
各ノードで、docker loginコマンドを使用して、Webインタフェースへのログインに使用したものと同じ資格証明を使用して、Oracle Container Registryミラー・サーバーに対して認証します。
```
# docker login container-registry-phx.oracle.com
```
このコマンドにより、ユーザー名とパスワードの入力を求められます。
ログイン後、Kubernetesのデプロイ時に正しいレジストリ・ミラーを使用するように環境変数を設定します。
```
# export KUBE_REPO_PREFIX=container-registry-phx.oracle.com/kubernetes
# echo 'export KUBE_REPO_PREFIX=container-registry-phx.oracle.com/kubernetes' > ~/.bashrc
```
Kubernetesと使用するOracle Linux Container ServicesをOracle Cloud Infrastructureで使用している場合、kubeadm-ha-setupツールにより、使用に最も適切なミラー・サーバーが自動的に検出され、この環境変数が設定されるため、このステップを実行する必要はありません。コマンドラインでKUBE_REPO_PREFIX環境変数を手動で設定した場合、kubeadm-ha-setupでは変数が優先され、使用する必要のあるミラー・サーバーの検出は試行されません。

3.2.5.2 オプションのローカル・レジストリの設定

Kubernetesクラスタ・ノードに使用するシステムにインターネットへの直接アクセスがなく、Oracle Container Registryに直接接続できない場合は、この機能を実行するローカルDockerレジストリを設定できます。kubeadm-ha-setupツールには、これらのイメージの取得に使用するレジストリを変更するオプションがあります。ローカルDockerレジストリを設定する手順は、Oracle® Linux: Oracle Container Runtime for Dockerユーザー・ガイドを参照してください。

ローカルDockerレジストリを設定したら、Kubernetesと使用するOracle Linux Container Servicesを実行するために必要なイメージをプルし、これらのイメージにタグ付けしてから、ローカル・レジストリにプッシュする必要があります。イメージは、Oracle Container Registryでのタグ付け方法と同様にタグ付けする必要があります。kubeadm-ha-setupは設定プロセス中にバージョン番号を照合し、特定のバージョンのイメージが見つからない場合には、多数の操作を正常に完了できません。このプロセスを支援するために、Kubernetesと使用するOracle Linux Container Servicesには、kubeadmパッケージのkubeadm-registry.shツールが用意されています。

kubeadm-registry.shツールを使用してOracle Container Registryからイメージを自動的にプルし、適切にタグ付けしてローカル・レジストリにプッシュするには、次のようにします。

Oracle Container Registryを使用してイメージを取得する場合は、第2.2.5項「Oracle Container Registryの要件」の手順に従ってログインします。Oracle Container Registryミラーのいずれかを使用する場合の詳細は、第3.2.5.1項「Oracle Container Registryミラーの使用方法」を参照してください。
必要なオプションを指定してkubeadm-registry.shツールを実行します。
```
# kubeadm-registry.sh --to host.example.com:5000
```
host.example.com:5000を、ローカルDockerレジストリが使用可能な解決できるドメイン名とポートに置き換えます。

オプションで、--fromオプションを使用して、イメージをプルする代替レジストリを指定できます。--versionオプションを使用して、ホストするKubernetesイメージのバージョンを指定することもできます。次に例を示します。
```
# kubeadm-registry.sh --to host.example.com:5000 --from \
  container-registry-phx.oracle.com/kubernetes --version 1.12.0
```

重要

環境をアップグレードし、ローカル・レジストリを使用する予定の場合は、Kubernetesと使用するOracle Linux Container Servicesの実行に必要な最新バージョンのイメージがあることを確認する必要があります。マスター・ノードでアップグレードを実行する前に、kubeadm-registry.shツールを使用して正しいイメージをプルし、ローカル・レジストリを更新できます。

ローカルDockerレジストリをインストールして構成し、必要なイメージをインポートしたら、kubeadm-ha-setupツールで使用するレジストリ・サーバーを制御する環境変数を設定する必要があります。kubeadm-ha-setupツールを実行する各システムで、次のコマンドを実行します。

# export KUBE_REPO_PREFIX="local-registry.example.com:5000/kubernetes"
# echo 'export KUBE_REPO_PREFIX="local-registry.example.com:5000/kubernetes"' > ~/.bashrc

local-registry.example.comを、ローカルDockerレジストリが構成されているホストのIPアドレスまたは解決可能なドメイン名に置き換えます。

3.2.6 ネットワーク・タイム・サービスの要件

クラスタリング環境としてのKubernetesでは、クラスタ内の各ノード間でシステム時間が同期されている必要があります。通常、これを行うには、各ノードにNTPデーモンをインストールして構成します。次に示す方法で実行できます。

ntpパッケージがまだインストールされていない場合はインストールします。
```
# yum install ntp
```
/etc/ntp.confのNTP構成を編集します。要件は異なる場合があります。各ノードのネットワーキングを構成するためにDHCPを使用する場合は、NTPサーバーを自動的に構成できます。システムの同期に使用できるNTPサービスがローカルに構成されておらず、インターネットにアクセスできる場合は、パブリックのpool.ntp.orgサービスを使用するようにシステムを構成できます。https://www.ntppool.org/en/を参照してください。
Kubernetesインストールに進む前に、NTPがブート時に再起動可能であり、起動されていることを確認してください。次に例を示します。
```
# systemctl start ntpd
# systemctl enable ntpd
```

Oracle Cloud Infrastructureで実行中のシステムは、デフォルトでchronydタイム・サービスを使用するように構成されているため、Oracle Cloud Infrastructure環境にインストールする場合、NTPを追加または構成する必要はありません。

ネットワーク・タイム・サービスの構成の詳細は、Oracle® Linux 7: 管理者ガイドを参照してください。

3.2.7 ファイアウォールとiptablesの要件

Kubernetesはiptablesを使用して多くのネットワーキングおよびポート転送のルールを処理します。そのため、Kubernetesの機能を妨げる可能性のあるルール・セットがないことを確認する必要があります。kubeadm-ha-setupツールでは、転送トラフィックを受け入れるためのiptablesルールが必要です。このルールが設定されていない場合、ツールは終了し、このiptablesルールの追加が必要な可能性があることが通知されます。標準のDockerインストールでは、転送を妨げるファイアウォール・ルールが作成されることがあるため、次の実行が必要になる場合があります。

# iptables -P FORWARD ACCEPT

kubeadm-ha-setupツールによりiptablesルールがチェックされ、一致がある場合は、要件を満たすためにiptables構成を変更する方法の手順が示されます。詳細は、第4.1項「Kubernetesとiptablesのルール」を参照してください。

Kubernetesがデプロイされているシステムでファイアウォールを直接実行する要件がある場合は、Kubernetesに必要なすべてのポートが使用可能であることを確認する必要があります。たとえば、他のノードでAPIサーバーにアクセスできるようにするには、マスター・ノードでTCPポート6443にアクセスできる必要があります。すべてのノードがTCPポート10250-10252および10255上のマスター・ノードからの接続を受け入れることができ、トラフィックがUDPポート8472で許可されている必要があります。すべてのノードで、Kubernetesポッドに使用されるネットワーク・ファブリック上のすべてのポートのその他すべてのノードから、トラフィックを受信できる必要があります。ファイアウォールで、マスカレードがサポートされている必要があります。

Oracle Linux 7により、デフォルトでfirewalldがインストールされ、有効化されます。firewalldを実行している場合、kubeadm-ha-setupツールにより、追加が必要な可能性のあるルールが通知されます。要約すると、すべてのノードで次のコマンドを実行します。

# firewall-cmd --add-masquerade --permanent

# firewall-cmd --add-port=2379-2380/tcp --permanent
# firewall-cmd --add-port=10250/tcp --permanent
# firewall-cmd --add-port=10251/tcp --permanent
# firewall-cmd --add-port=10252/tcp --permanent
# firewall-cmd --add-port=10255/tcp --permanent
# firewall-cmd --add-port=8472/udp --permanent

さらに、マスター・クラスタ内の各ノードで次のコマンドを実行して、APIアクセスを有効にします。

# firewall-cmd --add-port=6443/tcp --permanent

--permanentオプションを指定すると、これらのファイアウォール・ルールは再起動後も保持されます。これらのルールを有効にするには、ファイアウォールを忘れずに再起動してください。

# systemctl restart firewalld

3.2.8 ネットワーク要件

kubeadm-ha-setupツールでは、Oracle Container Registryおよび場合によってはその他のインターネット・リソースにアクセスして、必要なコンテナ・イメージをプルできる必要があります。したがって、コンテナ・イメージのすべての要件に対してローカル・ミラーを設定する予定がない場合、Kubernetesをインストールするシステムは、インターネットに直接アクセス可能であるか、プロキシを使用するように構成する必要があります。詳細は、第4.2項「プロキシ・サーバーでのKubernetesの使用方法」を参照してください。

kubeadm-ha-setupツールにより、br_netfilterモジュールがロードされているかどうかがチェックされ、使用できない場合、ツールは終了します。クラスタ全体のKubernetesポッド間の通信のために、このモジュールで透過マスカレードを有効にし、Virtual Extensible LAN (VxLAN)トラフィックを容易にする必要があります。ロードされているかどうかを確認する必要がある場合は、次を実行します。

# lsmod|grep br_netfilter

通常、カーネル・モジュールは必要に応じてロードされます。ほとんどの場合、このモジュールを手動でロードする必要はありません。ただし、必要に応じて、次を実行してモジュールを手動でロードできます。

# modprobe br_netfilter
# echo "br_netfilter" > /etc/modules-load.d/br_netfilter.conf

Kubernetesでは、ネットワーク・ブリッジを通過するパケットが、フィルタリングおよびポート転送のためにiptablesによって処理されている必要があります。これを実現するために、kubeadmパッケージのインストール時にカーネル・ブリッジ・モジュールの調整可能なパラメータが自動的に設定され、/etc/sysctl.d/k8s.confに次の行を含むsysctlファイルが作成されます。

net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1

このファイルを変更するか、同様のものを独自に作成する場合は、次のコマンドを実行してブリッジの調整可能なパラメータをロードする必要があります。

# /sbin/sysctl -p /etc/sysctl.d/k8s.conf

kubeadm-ha-setupツールにより、Kubernetesポッド間の通信に使用されるネットワーク・ファブリックとして、flannelネットワークが構成されます。このオーバーレイ・ネットワークでは、ネットワーク接続を容易にするためにVxLANを使用します(https://github.com/coreos/flannel)。

デフォルトでは、このネットワークをホストするために、kubeadm-ha-setupツールにより10.244.0.0/16範囲内にネットワークが作成されます。kubeadm-ha-setupツールには、インストール時、必要に応じてネットワーク範囲を代替範囲に設定するオプションがあります。Kubernetesデプロイメント内のシステムでは、この予約されたIP範囲用にネットワーク・デバイスを構成することはできません。

3.2.9 SELinux要件

kubeadm-ha-setupツールにより、SELinuxが強制モードに設定されているかどうかがチェックされます。強制モードが有効になっている場合、ツールはSELinuxを許可モードに設定するようにリクエストするエラーで終了します。SELinuxを許可モードに設定すると、コンテナからポッド・ネットワークに必要なホスト・ファイル・システムにアクセスできるようになります。これは、SELinuxサポートがKubernetesのkubeletツールで改善されるまでの要件となります。

SELinuxを一時的に無効にするには、次を実行します。

# /usr/sbin/setenforce 0

Kubernetesが正しく動作し続けるように、以降の再起動でSELinuxの強制モードを無効にするには、/etc/selinux/configを変更し、SELinux変数を設定します。

SELINUX=Permissive

3.2.10 Oracle Cloud InfrastructureでKubernetesと使用するOracle Linux Container Servicesを使用するための要件

Kubernetesと使用するOracle Linux Container Servicesは、Oracle Cloud Infrastructure上で動作するように設計されています。このドキュメントに記載されているすべての手順は、コンピュート・インスタンスのグループ全体にわたりKubernetesをインストールして構成するために使用できます。Oracle Cloud Infrastructureの構成ステップおよび使用方法の詳細は、次を参照してください。

https://docs.cloud.oracle.com/iaas/Content/home.htm

Oracle Cloud Infrastructure上でのKubernetesと使用するOracle Linux Container Servicesにとって最も重要な要件は、仮想クラウド・ネットワーク(VCN)により、Kubernetesデプロイメントで使用されているコンピュート・ノードが必要なポートで通信できることです。デフォルトでは、適切なイングレス・ルールを使用してセキュリティ・リストを構成するまで、コンピュート・ノードは仮想クラウド・ネットワークを介して相互にアクセスできません。

イングレス・ルールは、第3.2.7項「ファイアウォールとiptablesの要件」で説明されているとおり、ファイアウォール構成に必要なルールと一致する必要があります。通常、このためには、次のイングレス・ルールをVCNのデフォルトのセキュリティ・リストに追加する必要があります。

2379-2380/TCPを許可します。
- ステートレス: 選択解除
- ソースCIDR: 10.0.0.0/16
- IPプロトコル: TCP
- ソース・ポート範囲: すべて
- 宛先ポート範囲: 2379-2380
6443/TCPを許可します。
- ステートレス: 選択解除
- ソースCIDR: 10.0.0.0/16
- IPプロトコル: TCP
- ソース・ポート範囲: すべて
- 宛先ポート範囲: 6443
10250-10252/TCPを許可します。
- ステートレス: 選択解除
- ソースCIDR: 10.0.0.0/16
- IPプロトコル: TCP
- ソース・ポート範囲: すべて
- 宛先ポート範囲: 10250-10252
10255/TCPを許可します。
- ステートレス: 選択解除
- ソースCIDR: 10.0.0.0/16
- IPプロトコル: TCP
- ソース・ポート範囲: すべて
- 宛先ポート範囲: 10255
8472/UDPを許可します。
- ステートレス: 選択解除
- ソースCIDR: 10.0.0.0/16
- IPプロトコル: UDP
- ソース・ポート範囲: すべて
- 宛先ポート範囲: 8472

10.0.0.0/16を、Kubernetesクラスタに追加するコンピュート・ノードのVCN内に作成したサブネットで使用する範囲に置き換えます。これは、特にクラスタ・コンポーネントによって使用される特定のIPアドレス範囲に限定する必要がある場合も、独自のセキュリティ要件に応じてより広範に設定する場合もあります。

重要

ここで説明するイングレス・ルールは、クラスタが機能できるように設定する必要があるコア・ルールです。定義するサービスまたは使用する予定のサービスごとに、セキュリティ・リストに追加のルールを定義することが必要になる場合があります。

Kubernetesと使用するOracle Linux Container Servicesをホストするコンピュート・インスタンスを作成する場合は、すべてのシェイプ・タイプがサポートされます。高可用性クラスタの場合は、Unbreakable Enterprise Kernelリリース5 (UEK R5)でOracle Linux 7 Update 5イメージ以降を使用する環境が必要です。

ロード・バランシングの構成で説明されているように、Oracle Cloud Infrastructureを使用しながら、マスター・クラスタに対してロード・バランサを構成する予定がある場合は、次を参照してください。

https://docs.cloud.oracle.com/en-us/iaas/Content/Balance/Concepts/balanceoverview.htm

3.3 マスター・クラスタの設定

開始する前に、第3.2.5項「Oracle Container Registryの要件」に記載されている要件を満たしていることを確認してください。次に、マスター・ノードとして構成するすべてのホストで、kubeadmおよびkubeadm-ha-setupパッケージとその依存関係をインストールします。

# yum install kubeadm kubelet kubectl kubeadm-ha-setup

続行する前に、高可用性マスター・クラスタ内のノードを定義します。テンプレート構成ファイルを生成するには、/usr/local/share/kubeadm/kubeadm-ha/ha.yamlのマスター・クラスタ内の任意のノードで提供されたファイルをコピーします。

# cp /usr/local/share/kubeadm/kubeadm-ha/ha.yaml ~/ha.yaml

最初のステップは、masterクラスタで使用される各ノードのサーバーIPアドレスを指定することです。このクラスタには3つのノードが定義されている必要があり、それぞれに一意のホスト名が必要です。

clusters:
- name: master
  vip: 192.0.2.13
  nodes:
  - 192.0.2.10
  - 192.0.2.11
  - 192.0.2.12

クラスタのvipアドレスは、クラスタのキープアライブ・サービスを実行中のサーバーのIPアドレスです。このサービスはデフォルトでOracle Linux 7に含まれ、このサービスの詳細は、Oracle® Linux 7: 管理者ガイドを参照してください。

kubeadm-ha-setupの使用時は常に、クラスタ内のすべてのマスター・ノードに、他のマスター・ノードに対するパスワードなしのキーベースの認証を使用したシェル・アクセスが必要です。SSHキーを構成するには、Oracle® Linux 7: 管理者ガイドの手順に従います。

SSH秘密キーはprivate_key変数で定義する必要があり、リモート・ユーザーの場合にはuser変数で定義する必要があります。

  private_key: /root/.ssh/id_rsa
  user: root

オプションで、ポッド・ネットワークに対してpod_cidrを定義できます。デフォルトでは、これは予約されたローカルIP範囲に設定されています。

  pod_cidr: 10.244.0.0/16

現在のリリースのコンテナ・イメージをフェッチできるよう、Oracle Container RegistryまたはOracle Container Registryミラーを指すようにimage変数を設定します。ミラーの使用方法の詳細は、第3.2.5.1項「Oracle Container Registryミラーの使用方法」を参照してください。

  image: container-registry.oracle.com/kubernetes
  k8sversion: v1.12.5

これらの設定を適用し、他のマスター・ノードを自動的にプロビジョニングするには、マスター・クラスタ内の1つのKubernetesノードで、kubeadm-setup.sh upのかわりにkubeadm-ha-setup upを実行します。

rootとして、kubeadm-ha-setupを実行し、ホストをマスター・ノードとして追加します。

# kubeadm-ha-setup up ~/ha.yaml
Cleaning up ...
Reading configuration file /usr/local/share/kubeadm/kubeadm-ha/ha.yaml ...
CreateSSH /root/.ssh/id_rsa root

Checking 192.0.2.10
status 0

Checking 192.0.2.11
status 0

Checking 192.0.2.12
status 0

Configuring keepalived for HA ...
success
success
Setting up first master ... (maximum wait time 185 seconds)
[init] using Kubernetes version: v1.12.5
[preflight] running pre-flight checks
[preflight/images] Pulling images required for setting up a Kubernetes cluster
[preflight/images] This might take a minute or two, 
depending on the speed of your internet connection
[preflight/images] You can also perform this action beforehand using 'kubeadm config images pull'
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[preflight] Activating the kubelet service
[certificates] Generated front-proxy-ca certificate and key.
[certificates] Generated front-proxy-client certificate and key.
[certificates] Generated etcd/ca certificate and key.
[certificates] Generated etcd/server certificate and key.
[certificates] etcd/server serving cert is signed for DNS names 
[master1.example.com localhost] and IPs [127.0.0.1 ::1 192.0.2.10]
[certificates] Generated etcd/peer certificate and key.
[certificates] etcd/peer serving cert is signed for DNS names 
[master1.example.com localhost] and IPs [192.0.2.10 127.0.0.1 ::1 192.0.2.10]
[certificates] Generated apiserver-etcd-client certificate and key.
[certificates] Generated etcd/healthcheck-client certificate and key.
[certificates] Generated ca certificate and key.
[certificates] Generated apiserver certificate and key.
[certificates] apiserver serving cert is signed for DNS names 
[master1.example.com kubernetes kubernetes.default 
kubernetes.default.svc kubernetes.default.svc.cluster.local] and
 IPs [10.96.0.1 192.0.2.10 192.0.2.10 192.0.2.10 192.0.2.11 192.0.2.12 192.0.2.10]
[certificates] Generated apiserver-kubelet-client certificate and key.
[certificates] valid certificates and keys now exist in "/etc/kubernetes/pki"
[certificates] Generated sa key and public key.
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[controlplane] wrote Static Pod manifest for component kube-apiserver 
to "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] wrote Static Pod manifest for component kube-controller-manager 
to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
[init] waiting for the kubelet to boot up the control plane as Static Pods 
from directory "/etc/kubernetes/manifests"
[init] this might take a minute or longer if the control plane images have to be pulled
[apiclient] All control plane components are healthy after 27.004111 seconds
[uploadconfig] storing the configuration used in 
ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.12" 
in namespace kube-system with the configuration for the kubelets in the cluster
[markmaster] Marking the node master1.example.com as master 
by adding the label "node-role.kubernetes.io/master=''"
[markmaster] Marking the node master1.example.com as master 
by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" 
to the Node API object "master1.example.com" as an annotation
[bootstraptoken] using token: ixxbh9.zrtxo7jwo1uz2ssp
[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens 
to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] configured RBAC rules to allow the csrapprover controller 
automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] configured RBAC rules to allow certificate rotation 
for all node client certificates in the cluster
[bootstraptoken] creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of machines by running the following on each node
as root:

  kubeadm-ha-setup join container-registry.oracle.com/kubernetes:v1.12.5 192.0.2.10:6443 \
 --token ixxbh9.zrtxo7jwo1uz2ssp \
--discovery-token-ca-cert-hash \
sha256:6459031d2993f672f5a47f1373f009a3ce220ceddd6118f14168734afc0a43ad


Attempting to send file to:  192.0.2.11:22
Attempting to send file to:  192.0.2.12:22
Setting up master on 192.0.2.11
[INFO] 192.0.2.11 added   
Setting up master on 192.0.2.12
[INFO] 192.0.2.12 added   
Installing flannel and dashboard ...
[SUCCESS] Complete synchronization between nodes may take a few minutes.

注意

後日クラスタの再作成が必要になった場合に備えて、共有記憶域または外部記憶域に~/ha.yamlファイルをバックアップする必要があります。

ロード・バランシングの構成

高可用性マスター・クラスタ構成の一部としてロード・バランサをサポートするには、そのIPアドレスを~/ha.yamlファイルのloadbalancer値として設定します。

 loadbalancer: 192.0.2.15

loadbalancer値は、次のコマンドを使用して、設定プロセスの一部として適用されます。

# kubeadm-ha-setup up ~/ha.yaml --lb

この構成ステップはオプションですが、これが含まれる場合は、すべてのマスター・ノードについてポート6443が開いていることを確認してください。第3.2.7項「ファイアウォールとiptablesの要件」を参照してください。

Kubernetesを一般ユーザーとして使用する準備

Kubernetesクラスタを一般ユーザーとして使用するには、マスター・クラスタ内の各ノードで次のステップを実行します。

.kubeサブディレクトリをホーム・ディレクトリ内に作成します。
```
$ mkdir -p $HOME/.kube
```
Kubernetes admin.confファイルのコピーを.kubeディレクトリ内に作成します。
```
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
```
ファイルの所有権を一般ユーザー・プロファイルと一致するように変更します。
```
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config
```
ファイルへのパスをKUBECONFIG環境変数にエクスポートします。
```
$ export KUBECONFIG=$HOME/.kube/config
```
このファイルへのパスがこの環境変数に設定されていない場合は、kubectlコマンドを使用できません。以降のログインごとにKUBECONFIG変数を忘れずにエクスポートし、kubectlおよびkubeadmコマンドで、正しいadmin.confファイルが使用されるようにしてください。そうしないと、再起動または新規ログイン後、これらのコマンドが予期したとおりに動作しないことがあります。たとえば、エクスポート行を.bashrcに追加します。
```
$ echo 'export KUBECONFIG=$HOME/.kube/config' >> $HOME/.bashrc
```

kubectlコマンドが使用できることを確認します。

Kubernetesでは、多数のサービスを実行して、Kubernetesポッドとして実行されるDockerコンテナとしてクラスタ構成を管理します。これらを表示するには、マスター・ノードで次のコマンドを実行します。

$ kubectl get pods -n kube-system
NAME                                   READY   STATUS             RESTARTS   AGE
coredns-6c77847dcf-mxjqt               1/1     Running            0          12m
coredns-6c77847dcf-s6pgz               1/1     Running            0          12m
etcd-master1.example.com               1/1     Running            0          11m
etcd-master2.example.com               1/1     Running            0          11m
etcd-master3.example.com               1/1     Running            0          11m
kube-apiserver-master1.example.com     1/1     Running            0          11m
kube-apiserver-master2.example.com     1/1     Running            0          11m
kube-apiserver-master3.example.com     1/1     Running            0          11m
kube-controller-master1.example.com    1/1     Running            0          11m
kube-controller-master2.example.com    1/1     Running            0          11m
kube-controller-master3.example.com    1/1     Running            0          11m
kube-flannel-ds-z77w9                  1/1     Running            0          12m
kube-flannel-ds-n8t99                  1/1     Running            0          12m
kube-flannel-ds-pkw2l                  1/1     Running            0          12m
kube-proxy-zntpv                       1/1     Running            0          12m
kube-proxy-p5kfv                       1/1     Running            0          12m
kube-proxy-x7rfh                       1/1     Running            0          12m
kube-scheduler-master1.example.com     1/1     Running            0          11m
kube-scheduler-master2.example.com     1/1     Running            0          11m
kube-scheduler-master3.example.com     1/1     Running            0          11m
kubernetes-dashboard-64458f66b6-2l5n6  1/1     Running            0          12m

3.4 ワーカー・ノードの設定

ワーカー・ノードとしてクラスタに追加する各ホストで、これらのステップを繰り返します。

kubeadmパッケージとその依存関係をインストールします。

# yum install kubeadm kubelet kubectl kubeadm-ha-setup

rootとして、kubeadm-ha-setup joinコマンドを実行し、ホストをワーカー・ノードとして追加します。

# kubeadm-ha-setup join container-registry.oracle.com/kubernetes:v1.12.5 192.0.2.13:6443 \
   --token ixxbh9.zrtxo7jwo1uz2ssp --discovery-token-ca-cert-hash \
      sha256:6459031d2993f672f5a47f1373f009a3ce220ceddd6118f14168734afc0a43ad
Trying to pull image kube-proxy v1.12.5 from container-registry.oracle.com/kubernetes
Cleaning up ...
[preflight] running pre-flight checks
[discovery] Trying to connect to API Server "192.0.2.13:6443"
[discovery] Created cluster-info discovery client, 
requesting info from "https://192.0.2.13:6443"
[discovery] Requesting info from "https://192.0.2.13:6443" again 
to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates 
against pinned roots, will use API Server "192.0.2.13:6443"
[discovery] Successfully established connection with API Server "192.0.2.13:6443"
[kubelet] Downloading configuration for the kubelet from 
the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" 
to the Node API object "worker1.example.com" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the master to see this node join the cluster.

IPアドレスとポート(192.0.2.13:6443)を、マスタークラスタで使用されるvipまたはloadbalancerに設定されたIPアドレスとポートに置き換えます。デフォルトのポートは6443であり、使用する必要があるIPアドレスは、kubectl cluster-infoを使用して確認できます。

ワーカーが高可用性クラスタに正常に追加されたことを確認するには、マスター・クラスタの任意のノードでkubectl get nodeを実行します。

$ kubectl get nodes
NAME                  STATUS   ROLES    AGE     VERSION
master1.example.com   Ready    master   10m     v1.12.5+2.1.1.el7
master2.example.com   Ready    master   9m56s   v1.12.5+2.1.1.el7
master3.example.com   Ready    master   9m16s   v1.12.5+2.1.1.el7
worker1.example.com   Ready    <none>   2m26s   v1.12.5+2.1.1.el7

3.5 アップグレード

3.5.1 高可用性クラスタの更新

Kubernetesと使用するOracle Linux Container Services 1.1.12は、高可用性クラスタをサポートする最初のリリースです。

重要

オラクル社は、kubeadm-setup.shスクリプトを使用して構築された既存の単一マスター・ノード・クラスタの高可用性クラスタへのアップグレードをサポートしていません。高可用性クラスタは、kubeadm-ha-setupユーティリティを使用して構築および管理する必要があります。

同様に、高可用性クラスタ内のマスター・ノードのkubeadm-setup.shスクリプトを使用したアップグレードはサポートされていません。高可用性クラスタ内のすべてのメンテナンスおよび管理操作は、kubeadm-ha-setupユーティリティを使用して実行する必要があります。

3.5.1 高可用性クラスタの更新

重要

kubeadm-ha-setup updateコマンドは、既存の高可用性クラスタのエラータ・リリース更新でのみサポートされます。

大規模なアップグレード用のkubeadm-ha-setup upgradeコマンドは、今後のリリースで提供されます。現時点では、メジャー・リリース・アップグレードはサポートされていません。

エラータ・リリース更新のステップ

第4.3項「クラスタのバックアップおよびリストア」の手順に従って、続行する前に高可用性クラスタのバックアップを作成します。
クラスタ内の各マスター・ノードで、kubeadm-ha-setupパッケージを更新します。
```
# yum update kubeadm-ha-setup
```
クラスタ更新の実行元のマスター・ノードで、必要な前提条件パッケージを更新します。
```
# yum update kubeadm
```
Oracle Container Registryを使用してイメージを取得する場合は、ログインします。

第3.2.5項「Oracle Container Registryの要件」の手順に従います。Oracle Container Registryでイメージが更新された場合、更新を実行するには、Oracle標準の条件および制約を再度受け入れることが必要になる可能性があります。Oracle Container Registryミラーのいずれかを使用する場合の詳細は、第3.2.5.1項「Oracle Container Registryミラーの使用方法」を参照してください。ローカル・レジストリを構成している場合は、適切なレジストリを指すようにKUBE_REPO_PREFIX環境変数を設定することが必要になる可能性があります。アップグレード先のバージョンの最新のイメージを使用して、ローカル・レジストリを更新することが必要になる場合もあります。詳細は、第3.2.5.2項「オプションのローカル・レジストリの設定」を参照してください。

現在報告されているノード・バージョンが前のパッケージのバージョンと一致することを確認します。

# kubectl get nodes
NAME                  STATUS   ROLES    AGE     VERSION
master1.example.com   Ready    master   4m8s    v1.12.5+2.1.1.el7
master2.example.com   Ready    master   2m25s   v1.12.5+2.1.1.el7
master3.example.com   Ready    master   2m12s   v1.12.5+2.1.1.el7
worker1.example.com   Ready    <none>   25s     v1.12.5+2.1.1.el7

kubeadm-ha-setupツールを使用して、スクリプト化された更新プロセスを開始します。

# kubeadm-ha-setup update
[WARNING] This action will update this cluster to the latest version(1.12.7).
[WARNING] You must take a backup before updating the cluster, as the update may fail. 
[PROMPT] Do you want to continue updating your cluster?
Please type Yes/y to confirm or No/n to abort(Case insensitive):
Y
Kubernetes Cluster Version: v1.12.5
Kubeadm version:1.12.7-1.1.2, Kueblet version 1.12.5-2.1.1
Kubeadm version: 1.12.5-2.1.1 Kubelet version: 1.12.7-1.1.2
Reading configuration file /usr/local/share/kubeadm/run/kubeadm/ha.yaml ...
Checking repo access
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 
'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade/apply] Respecting the --cri-socket flag that is set 
with higher priority than the config file.
[upgrade/version] You have chosen to change the cluster version to "v1.12.7"
[upgrade/versions] Cluster version: v1.12.5+2.1.1.el7
[upgrade/versions] kubeadm version: v1.12.7+1.1.2.el7
[upgrade/prepull] Will prepull images for components 
[kube-apiserver kube-controller-manager kube-scheduler etcd]
[upgrade/prepull] Prepulling image for component etcd.
[upgrade/prepull] Prepulling image for component kube-apiserver.
[upgrade/prepull] Prepulling image for component kube-controller-manager.
[upgrade/prepull] Prepulling image for component kube-scheduler.
[apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-etcd
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-controller-manager
[apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
[apiclient] Found 3 Pods for label selector k8s-app=upgrade-prepull-kube-apiserver
[apiclient] Found 3 Pods for label selector k8s-app=upgrade-prepull-etcd
[apiclient] Found 3 Pods for label selector k8s-app=upgrade-prepull-kube-controller-manager
[apiclient] Found 3 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
[upgrade/prepull] Prepulled image for component kube-apiserver.
[upgrade/prepull] Prepulled image for component kube-controller-manager.
[upgrade/prepull] Prepulled image for component kube-scheduler.
[upgrade/prepull] Prepulled image for component etcd.
[upgrade/prepull] Successfully prepulled the images for all the control plane components
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.12.7"...
Static pod: kube-apiserver-master1.example.com hash: 
f9004e982ed918c6303596943cef5493
Static pod: kube-controller-manager-master1.example.com hash: 
9590101be574fc0a237ca3f029f03ea2
Static pod: kube-scheduler-master1.example.com hash: 
22961405d099beb7721c7598daaa73d6
[upgrade/staticpods] Writing new Static Pod manifests to 
"/etc/kubernetes/tmp/kubeadm-upgraded-manifests867609756"
[controlplane] wrote Static Pod manifest for component kube-apiserver to 
"/etc/kubernetes/tmp/kubeadm-upgraded-manifests867609756/kube-apiserver.yaml"
[controlplane] wrote Static Pod manifest for component kube-controller-manager to 
"/etc/kubernetes/tmp/kubeadm-upgraded-manifests867609756/kube-controller-manager.yaml"
[controlplane] wrote Static Pod manifest for component kube-scheduler to 
"/etc/kubernetes/tmp/kubeadm-upgraded-manifests867609756/kube-scheduler.yaml"
[upgrade/staticpods] Moved new manifest to 
"/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to 
"/etc/kubernetes/tmp/kubeadm-backup-manifests-2019-04-08-14-28-11/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on 
the component/version gap (timeout 5m0s
Static pod: kube-apiserver-master1.example.com hash: f9004e982ed918c6303596943cef5493
Static pod: kube-apiserver-master1.example.com hash: f9004e982ed918c6303596943cef5493
Static pod: kube-apiserver-master1.example.com hash: f9004e982ed918c6303596943cef5493
Static pod: kube-apiserver-master1.example.com hash: a692b9726292a4c2a89e2cdcd8301035
[apiclient] Found 3 Pods for label selector component=kube-apiserver
[upgrade/staticpods] Component "kube-apiserver" upgraded successfully!
[upgrade/staticpods] Moved new manifest to 
"/etc/kubernetes/manifests/kube-controller-manager.yaml" and 
backed up old manifest to 
"/etc/kubernetes/tmp/kubeadm-backup-manifests-2019-04-08-14-28-11/
kube-controller-manager.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on 
the component/version gap (timeout 5m0s
Static pod: kube-controller-manager-master1.example.com hash: 
9590101be574fc0a237ca3f029f03ea2
Static pod: kube-controller-manager-master1.example.com hash: 
7dbb816a4ac17a9522e761017dcd444c
[apiclient] Found 3 Pods for label selector component=kube-controller-manager
[upgrade/staticpods] Component "kube-controller-manager" upgraded successfully!
[upgrade/staticpods] Moved new manifest to 
"/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to 
"/etc/kubernetes/tmp/kubeadm-backup-manifests-2019-04-08-14-28-11/kube-scheduler.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/staticpods] This might take a minute or longer depending on 
the component/version gap (timeout 5m0s
Static pod: kube-scheduler-master1.example.com hash: 22961405d099beb7721c7598daaa73d6
Static pod: kube-scheduler-master1.example.com hash: 980091350a77a7fbcff570589689adc2
[apiclient] Found 3 Pods for label selector component=kube-scheduler
[upgrade/staticpods] Component "kube-scheduler" upgraded successfully!
[uploadconfig] storing the configuration used in 
ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.12" in namespace kube-system 
with the configuration for the kubelets in the cluster
[kubelet] Downloading configuration for the kubelet from 
the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to 
the Node API object "master1.example.com" as an annotation
[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to 
post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] configured RBAC rules to allow the csrapprover controller 
automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] configured RBAC rules to allow certificate rotation for 
all node client certificates in the cluster
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.12.7". Enjoy!

[upgrade/kubelet] Now that your control plane is upgraded, please proceed with 
upgrading your kubelets if you haven't already done so.
Loaded plugins: langpacks, ulninfo
Resolving Dependencies
--> Running transaction check
---> Package kubelet.x86_64 0:1.12.5-2.1.1.el7 will be updated
---> Package kubelet.x86_64 0:1.12.7-1.1.2.el7 will be an update
--> Processing Dependency: conntrack for package: kubelet-1.12.7-1.1.2.el7.x86_64
--> Running transaction check
---> Package conntrack-tools.x86_64 0:1.4.4-4.el7 will be installed
--> Processing Dependency: libnetfilter_cttimeout.so.1(LIBNETFILTER_CTTIMEOUT_1.1)(64bit) 
for package: conntrack-tools-1.4.4-4.el7.x86_64
--> Processing Dependency: libnetfilter_cttimeout.so.1(LIBNETFILTER_CTTIMEOUT_1.0)(64bit) 
for package: conntrack-tools-1.4.4-4.el7.x86_64
--> Processing Dependency: libnetfilter_cthelper.so.0(LIBNETFILTER_CTHELPER_1.0)(64bit) 
for package: conntrack-tools-1.4.4-4.el7.x86_64
--> Processing Dependency: libnetfilter_cttimeout.so.1()(64bit) 
for package: conntrack-tools-1.4.4-4.el7.x86_64
--> Processing Dependency: libnetfilter_cthelper.so.0()(64bit) 
for package: conntrack-tools-1.4.4-4.el7.x86_64
--> Processing Dependency: libnetfilter_queue.so.1()(64bit) 
for package: conntrack-tools-1.4.4-4.el7.x86_64
--> Running transaction check
---> Package libnetfilter_cthelper.x86_64 0:1.0.0-9.el7 will be installed
---> Package libnetfilter_cttimeout.x86_64 0:1.0.0-6.el7 will be installed
---> Package libnetfilter_queue.x86_64 0:1.0.2-2.el7_2 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package                   Arch      Version                Repository     Size
================================================================================
Updating:
 kubelet                   x86_64    1.12.7-1.1.2.el7       ol7_addons        19 M
Installing for dependencies:
 conntrack-tools           x86_64    1.4.4-4.el7            ol7_latest    186 k
 libnetfilter_cthelper     x86_64    1.0.0-9.el7            ol7_latest     17 k
 libnetfilter_cttimeout    x86_64    1.0.0-6.el7            ol7_latest     17 k
 libnetfilter_queue        x86_64    1.0.2-2.el7_2          ol7_latest     22 k

Transaction Summary
================================================================================
Install             ( 4 Dependent packages)
Upgrade  1 Package

Total download size: 19 M
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
--------------------------------------------------------------------------------
Total                                              5.2 MB/s |  19 MB  00:03     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : libnetfilter_cthelper-1.0.0-9.el7.x86_64                     1/6 
  Installing : libnetfilter_cttimeout-1.0.0-6.el7.x86_64                    2/6 
  Installing : libnetfilter_queue-1.0.2-2.el7_2.x86_64                      3/6 
  Installing : conntrack-tools-1.4.4-4.el7.x86_64                           4/6 
  Updating   : kubelet-1.12.7-1.1.2.el7.x86_64                              5/6 
  Cleanup    : kubelet-1.12.5-2.1.1.el7.x86_64                              6/6 
  Verifying  : libnetfilter_queue-1.0.2-2.el7_2.x86_64                      1/6 
  Verifying  : libnetfilter_cttimeout-1.0.0-6.el7.x86_64                    2/6 
  Verifying  : kubelet-1.12.7-1.1.2.el7.x86_64                              3/6 
  Verifying  : libnetfilter_cthelper-1.0.0-9.el7.x86_64                     4/6 
  Verifying  : conntrack-tools-1.4.4-4.el7.x86_64                           5/6 
  Verifying  : kubelet-1.12.5-2.1.1.el7.x86_64                              6/6 

Dependency Installed:
  conntrack-tools.x86_64 0:1.4.4-4.el7                                          
  libnetfilter_cthelper.x86_64 0:1.0.0-9.el7                                    
  libnetfilter_cttimeout.x86_64 0:1.0.0-6.el7                                   
  libnetfilter_queue.x86_64 0:1.0.2-2.el7_2                                     

Updated:
  kubelet.x86_64 0:1.12.7-1.1.2.el7                                             

Complete!
Loaded plugins: langpacks, ulninfo
Resolving Dependencies
--> Running transaction check
---> Package kubectl.x86_64 0:1.12.5-2.1.1.el7 will be updated
---> Package kubectl.x86_64 0:1.12.7-1.1.2.el7 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package         Arch           Version                  Repository        Size
================================================================================
Updating:
 kubectl         x86_64         1.12.7-1.1.2.el7         ol7_addons          7.7 M

Transaction Summary
================================================================================
Upgrade  1 Package

Total download size: 7.7 M
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Updating   : kubectl-1.12.7-1.1.2.el7.x86_64                              1/2 
  Cleanup    : kubectl-1.12.5-2.1.1.el7.x86_64                              2/2 
  Verifying  : kubectl-1.12.7-1.1.2.el7.x86_64                              1/2 
  Verifying  : kubectl-1.12.5-2.1.1.el7.x86_64                              2/2 

Updated:
  kubectl.x86_64 0:1.12.7-1.1.2.el7                                             

Complete!
Waiting for the cluster to become healthy
.Updating remote master nodes
CreateSSH /root/.ssh/id_rsa root
Updating the master node:  master2.example.com
Successfully updated the master node:  master2.example.com
Updating the master node:  master3.example.com
Successfully updated the master node:  master3.example.com
The cluster has been updated successfully
Please update the worker nodes in your cluster and do the following:
     1. On Master: kubectl drain worker1.example.com --ignore-daemonsets
     2. On Worker1: yum install -y \
kubeadm-1.12.7-1.1.2.el7 kubelet-1.12.7-1.1.2.el7 \
kubectl-1.12.7-1.1.2.el7 kubeadm-ha-setup-0.0.2-1.0.21.el7
     3. On Worker1: systemctl restart kubelet
     4. On Master: kubectl uncordon worker1.example.com
     5. Verify the update on master node: kubectl get nodes

オプションで、エラータ・リリース更新時に、--registryオプションを指定することで、デフォルトのコンテナ・レジストリの選択をオーバーライドできます。

# kubeadm-ha-setup update --registry container-registry-phx.oracle.com

ワーカー・ノードの更新に進む前に、マスター・ノードが正しく更新されていることを確認します。

# kubectl get nodes
NAME                  STATUS   ROLES    AGE   VERSION
master1.example.com   Ready    master   17m   v1.12.7+1.1.2.el7
master2.example.com   Ready    master   15m   v1.12.7+1.1.2.el7
master3.example.com   Ready    master   15m   v1.12.7+1.1.2.el7
worker1.example.com   Ready    <none>   13m   v1.12.5+2.1.1.el7

kubectlツールを使用して、クラスタから各ワーカー・ノードをドレインします。
```
# kubectl drain worker1.example.com --ignore-daemonsets
node/worker1.example.com cordoned
```
ワーカー・ノードで、これ以上のスケジューリングまたは新しいポッドが受入れ不可であることを確認します。
```
# kubectl get nodes
```
ドレインされたノードのステータスは、SchedulingDisabledに設定されている必要があることに注意してください。
各ワーカー・ノードで、必要なパッケージを最新バージョンにアップグレードし、kubeletサービスを再起動します。
```
# yum update kubeadm kubelet kubectl kubeadm-ha-setup
# systemctl restart kubelet
```

これで、各ワーカー・ノードのアップグレードが完了しました。マスター・クラスタからkubectlツールを使用して、これらのアップグレードをuncordonします。

# kubectl uncordon worker1.example.com
node/worker1.example.com uncordoned

ワーカー・ノードで新しいスケジュールおよびポッドが受入れ可能になったことを確認します。

# kubectl get nodes
NAME                  STATUS   ROLES    AGE   VERSION
master1.example.com   Ready    master   17m   v1.12.7+1.1.2.el7
master2.example.com   Ready    master   15m   v1.12.7+1.1.2.el7
master3.example.com   Ready    master   15m   v1.12.7+1.1.2.el7
worker1.example.com   Ready    <none>   13m   v1.12.7+1.1.2.el7

エラータ・リリース更新の失敗からのリカバリ

更新が正常に完了しない場合は、バックアップからクラスタ全体のリストアを実行する必要があります。リストア・プロセスが完了するまで、クラスタは新しいコマンドに応答しません。

リカバリ・ステップ

各ノードで更新された必須パッケージを確認します。
```
# yum list installed kubeadm kubelet kubectl
```
以前のバージョンのエラータ・バージョンにすでに更新されている個々のパッケージをダウングレードします。たとえば、kubeadmパッケージをダウングレードするには、次を実行します。
```
# yum downgrade kubeadm
```
注意

最新バージョンは常にエラータ・リリース更新のリカバリをサポートするように設計されているため、マスター・ノードでkubeadm-ha-setupパッケージをダウングレードしないでください。
第4.3項「クラスタのバックアップおよびリストア」のリストア・ステップに従いますが、--forceフラグを追加してバージョン・チェックをオーバーライドします。
```
# kubeadm-ha-setup restore /backups/master-backup-v1.12.5-2-1544442719.tar --force
```
リカバリが完了したら、高可用性クラスタの更新を再試行できます。