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

第2章 Kubernetesと使用するOracle Linux Container Servicesのインストール

目次

この章では、Oracle Linux 7ホストにKubernetesをインストールし、Kubernetesクラスタを構築するために必要なステップについて説明します。

2.1 概要

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

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

kubeadmユーティリティは、自動的にマスター・ノードを汚染して、このノードでその他のワークロードやコンテナが実行されないようにします。このことは、マスター・ノードに不要な負荷がかからないようにするためと、クラスタのマスター・ノードのバックアップとリストアを簡略化するために役立ちます。

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

2.2 要件

Kubernetesは、一般に、クラスタ内の複数のノードで機能するクラスタ環境です。単一ノード・クラスタを実行することはできますが、この場合、そもそもクラスタを使用する利点がなくなります。したがって、Kubernetesがインストールされた2つ以上のシステムで環境を構成する必要があります。

次の各項では、Oracle Linux 7システムにKubernetesをインストールおよび構成するために満たす必要があるその他の様々な要件について説明します。

注意

Kubernetesと使用するOracle Linux Container Services 1.12では、Unbreakable Enterprise Kernelリリース5 (UEK R5)以降を使用するようにシステムを構成し、このカーネルを使用してシステムをブートする必要があります。

Unbreakable Enterprise Kernelリリース4 (UEK R4)を引き続き使用し、かつKubernetesと使用するOracle Linux Container Services 1.1.9に基づく既存のクラスタがある場合は、これがご使用の環境で使用可能なサポートされている最後のリリースとなります。Unbreakable Enterprise Kernel Release 5 (UEK R5)を使用するようにシステムをアップグレードし、このカーネルを使用してシステムをブートすることをお薦めします。

2.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をサポートしていません。このドキュメントの指示に従っても、これらのリポジトリまたはチャネルが有効化されている場合や、これらのチャネルまたはリポジトリのソフトウェアがシステムにインストールされている場合は、プラットフォームがサポートされないことがあります。

2.2.2 UEK R5の設定

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

  1. 使用中のシステムが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

  2. 次のコマンドを実行して、システムをUEK R5にアップグレードします。 

    # yum update

    UEK R5をデフォルトのブート・カーネルにする方法の詳細は、Oracle® Linux 7: 管理者ガイドを参照してください。

  3. UEK R5カーネルがデフォルトのブート・カーネルでない場合はこれを選択して、システムを再起動します。 

    # systemctl reboot

2.2.3 リソース要件

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

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

# dmidecode -s system-uuid

各ノードの/var/lib/kubeletに、5 GB以上の空き領域を持つストレージ・ボリュームをマウントする必要があります。基礎となるDockerエンジンのために、空き領域が5 GB以上の追加ボリュームを/var/lib/dockerの各ノードにマウントする必要があります。

2.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ユーザー・ガイドを参照してください。

2.2.5 Oracle Container Registryの要件

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

  1. シングル・サインオン資格証明を使用して、Oracle Container RegistryのWebサイト(https://container-registry.oracle.com)にログインします。

  2. Webインタフェースを使用してContainer Servicesビジネスエリアに移動し、デプロイする予定のOracleソフトウェア・イメージのOracle標準の条件および制約を受け入れます。このビジネスエリア内の既存のすべてのリポジトリに適用される、グローバル契約を受け入れることができます。将来、このビジネスエリアに新しいリポジトリが追加された場合、アップグレードを実行する前に、これらの条件を再度受け入れることが必要になる場合があります。

  3. クラスタ内のノードとして使用される各システムが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ユーザー・ガイドを参照してください。

2.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ミラー・サーバーを使用するステップは、次のとおりです。

  1. シングル・サインオン資格証明を使用して、引き続きOracle Container RegistryのWebサイト(https://container-registry.oracle.com)にログインし、Webインタフェースを使用して、Oracle標準の条件および制約を受け入れる必要があります。

  2. 各ノードで、docker loginコマンドを使用して、Webインタフェースへのログインに使用したものと同じ資格証明を使用して、Oracle Container Registryミラー・サーバーに対して認証します。 

    # docker login container-registry-phx.oracle.com

    このコマンドにより、ユーザー名とパスワードの入力を求められます。

  3. ログイン後、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-setup.shスクリプトにより、使用に最も適切なミラー・サーバーが自動的に検出され、この環境変数が設定されるため、このステップを実行する必要はありません。コマンドラインでKUBE_REPO_PREFIX環境変数を手動で設定した場合、kubeadm-setup.shでは変数が優先され、使用する必要のあるミラー・サーバーの検出は試行されません。

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

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

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

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

  1. Oracle Container Registryを使用してイメージを取得する場合は、第2.2.5項「Oracle Container Registryの要件」の手順に従ってログインします。Oracle Container Registryミラーのいずれかを使用する場合の詳細は、第2.2.5.1項「Oracle Container Registryミラーの使用方法」を参照してください。

  2. 必要なオプションを指定して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.5
重要

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

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

# 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アドレスまたは解決可能なドメイン名に置き換えます。

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

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

  1. ntpパッケージがまだインストールされていない場合はインストールします。 

    # yum install ntp

  2. /etc/ntp.confのNTP構成を編集します。要件は異なる場合があります。各ノードのネットワーキングを構成するためにDHCPを使用する場合は、NTPサーバーを自動的に構成できます。システムの同期に使用できるNTPサービスがローカルに構成されておらず、インターネットにアクセスできる場合は、パブリックのpool.ntp.orgサービスを使用するようにシステムを構成できます。https://www.ntppool.org/en/を参照してください。

  3. Kubernetesインストールに進む前に、NTPがブート時に再起動可能であり、起動されていることを確認してください。次に例を示します。 

    # systemctl start ntpd
# systemctl enable ntpd

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

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

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

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

# iptables -P FORWARD ACCEPT

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

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

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

# firewall-cmd --add-masquerade --permanent
# firewall-cmd --add-port=10250/tcp --permanent
# firewall-cmd --add-port=8472/udp --permanent

さらに、マスター・ノードで次のコマンドを実行します。 

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

--permanentオプションを使用して、これらのファイアウォール・ルールが再起動後も保持されるようにします。

これらのルールを有効にするには、ファイアウォールを忘れずに再起動してください。 

# systemctl restart firewalld

2.2.8 ネットワーク要件

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

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

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

2.2.9 SELinux要件

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

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

# /usr/sbin/setenforce 0

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

SELINUX=Permissive

2.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デプロイメントで使用されているコンピュート・ノードが必要なポートで通信できることです。デフォルトでは、適切なイングレス・ルールを使用してセキュリティ・リストを構成するまで、コンピュート・ノードはVCNを介して相互にアクセスできません。

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

  1. 6443/TCPを許可します。 

    • ステートレス: 選択解除

    • ソースCIDR: 10.0.0.0/16

    • IPプロトコル: TCP

    • ソース・ポート範囲: すべて

    • 宛先ポート範囲: 6443

  2. 10250/TCPを許可します。 

    • ステートレス: 選択解除

    • ソースCIDR: 10.0.0.0/16

    • IPプロトコル: TCP

    • ソース・ポート範囲: すべて

    • 宛先ポート範囲: 10250

  3. 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以降を使用する環境が必要です。

注意

Kubernetesと使用するOracle Linux Container Servicesの将来のバージョンでは、既存の単一マスター・クラスタがKubeDNSからCoreDNSに移行されます。CoreDNSでは、Unbreakable Enterprise Kernelリリース5 (UEK R5)でOracle Linux 7 Update 5イメージ以降を使用する必要があります。

Kubernetesと使用するOracle Linux Container Services 1.1.9の既存のインストールは、Unbreakable Enterprise Kernelリリース4 (UEK R4)を使用してOracle Linux 7 Update 3イメージですでに実行可能ですが、今後の製品アップグレードを許可するには、環境をアップグレードする必要があります。

2.3 マスター・ノードの設定

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

# yum install kubeadm kubelet kubectl

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

# kubeadm-setup.sh up
Checking kubelet and kubectl RPM ...
Starting to initialize master node ...
Checking if env is ready ... 
Checking whether docker can pull busybox image ...
Checking access to container-registry.oracle.com/kubernetes...
Trying to pull repository container-registry.oracle.com/kube-proxy ...
v1.12.5: Pulling from container-registry.oracle.com/kube-proxy
Digest: sha256:9f57fd95dc9c5918591930b2316474d10aca262b5c89bba588f45c1b96ba6f8b
Status: Image is up to date for container-registry.oracle.com/kube-proxy:v1.12.5
Checking whether docker can run container ...
Checking firewalld settings ...
Checking iptables default rule ...
Checking br_netfilter module ...
Checking sysctl variables ...
Enabling kubelet ...
Created symlink from /etc/systemd/system/multi-user.target.wants/kubelet.service 
to /etc/systemd/system/kubelet.service.
Check successful, ready to run 'up' command ...
Waiting for kubeadm to setup master cluster...
Please wait ...
\ - 80% completed
Waiting for the control plane to become ready ...
...............
100% completed
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.extensions/kube-flannel-ds created

Installing kubernetes-dashboard ...

secret/kubernetes-dashboard-certs created
serviceaccount/kubernetes-dashboard created
role.rbac.authorization.k8s.io/kubernetes-dashboard-minimal created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard-minimal created
deployment.apps/kubernetes-dashboard created
service/kubernetes-dashboard created
Enabling kubectl-proxy.service ...
Starting kubectl-proxy.service ...

[===> PLEASE DO THE FOLLOWING STEPS BELOW: <===]

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 can now join any number of machines by running the following on each node
as root:

  export KUBE_REPO_PREFIX=container-registry.oracle.com/kubernetes && kubeadm-setup.sh join 192.0.2.10:6443 \
 --token 8tipwo.tst0nvf7wcaqjcj0 --discovery-token-ca-cert-hash \
sha256:f2a5b22b658683c3634459c8e7617c9d6c080c72dd149f3eb903445efe9d8346

ネットワーク範囲を指定しない場合、スクリプトでは、デフォルトのネットワーク範囲10.244.0.0/16を使用して、クラスタ内のポッド相互作用に使用される内部ネットワークを構成します。代替ネットワーク範囲を指定するには、--pod-network-cidrオプションを指定してスクリプトを実行します。たとえば、次のように、10.100.0.0/16範囲を使用するようにネットワークを設定します。 

# kubeadm-setup.sh up --pod-network-cidr 10.100.0.0/16

kubeadm-setup.shスクリプトにより、マスター・ノードの設定前に、ホストがすべての要件を満たしているかどうかがチェックされます。要件が満たされない場合は、推奨される修正とともにエラー・メッセージが表示されます。スクリプトを再度実行する前に、エラーを修正する必要があります。

kubeletのsystemdサービスは、マスター・ノードがシステムのブート時に常に起動されるように、ホスト上で自動的に有効になります。

kubeadm-setup.shスクリプトの出力には、クラスタにワーカー・ノードを追加するコマンドが示されます。後で使用するために、このコマンドをノートにとっておいてください。コマンドに表示されるトークンは、24時間のみ有効です。トークンの詳細は、第2.4項「ワーカー・ノードの設定」を参照してください。

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

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

  1. .kubeサブディレクトリをホーム・ディレクトリ内に作成します。 

    $ mkdir -p $HOME/.kube

  2. Kubernetes admin.confファイルのコピーを.kubeディレクトリ内に作成します。 

    $ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

  3. ファイルの所有権を一般ユーザー・プロファイルと一致するように変更します。 

    $ sudo chown $(id -u):$(id -g) $HOME/.kube/config

  4. ファイルへのパスをKUBECONFIG環境変数にエクスポートします。 

    $ export KUBECONFIG=$HOME/.kube/config
    注意

    このファイルへのパスがこの環境変数に設定されていない場合は、kubectlコマンドを使用できません。以降のログインごとにKUBECONFIG変数を忘れずにエクスポートし、kubectlおよびkubeadmコマンドで、正しいadmin.confファイルが使用されるようにしてください。そうしないと、再起動または新規ログイン後、これらのコマンドが予期したとおりに動作しないことがあります。

    たとえば、エクスポート行を.bashrcに追加します。 

    $ echo 'export KUBECONFIG=$HOME/.kube/config' >> $HOME/.bashrc

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

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

    $ kubectl get pods -n kube-system
NAME                                        READY   STATUS    RESTARTS   AGE
coredns-6c77847dcf-77grm                    1/1     Running   0          5m16s
coredns-6c77847dcf-vtk8k                    1/1     Running   0          5m16s
etcd-master.example.com                     1/1     Running   0          4m26s
kube-apiserver-master.example.com           1/1     Running   0          4m46s
kube-controller-manager-master.example.com  1/1     Running   0          4m31s
kube-flannel-ds-glwgx                       1/1     Running   0          5m13s
kube-proxy-tv2mj                            1/1     Running   0          5m16s
kube-scheduler-master.example.com           1/1     Running   0          4m32s
kubernetes-dashboard-64458f66b6-q8dzh       1/1     Running   0          5m13s

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

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

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

# yum install kubeadm kubelet kubectl

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

# kubeadm-setup.sh join 192.0.2.10:6443 --token 8tipwo.tst0nvf7wcaqjcj0 \
      --discovery-token-ca-cert-hash \
      sha256:f2a5b22b658683c3634459c8e7617c9d6c080c72dd149f3eb903445efe9d8346
Checking kubelet and kubectl RPM ...
Starting to initialize worker node ...
Checking if env is ready ...
Checking whether docker can pull busybox image ...
Checking access to container-registry.oracle.com/kubernetes...
Trying to pull repository container-registry.oracle.com/kubernetes/kube-proxy ... 
v1.12.5: Pulling from container-registry.oracle.com/kubernetes/kube-proxy
Digest: sha256:9f57fd95dc9c5918591930b2316474d10aca262b5c89bba588f45c1b96ba6f8b
Status: Image is up to date for container-registry.oracle.com/kubernetes/kube-proxy:v1.12.5
Checking whether docker can run container ...
Checking firewalld settings ...
Checking iptables default rule ...
Checking br_netfilter module ...
Checking sysctl variables ...
Enabling kubelet ...
Created symlink from /etc/systemd/system/multi-user.target.wants/kubelet.service 
to /etc/systemd/system/kubelet.service.
Check successful, ready to run 'join' command ...
[validation] WARNING: kubeadm doesn't fully support multiple API Servers yet
[preflight] running pre-flight checks
[discovery] Trying to connect to API Server "192.0.2.10:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://192.0.2.10:6443"
[discovery] Trying to connect to API Server "192.0.2.10:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://192.0.2.10:6443"
[discovery] Requesting info from "https://192.0.2.10:6443" again 
to validate TLS against the pinned public key
[discovery] Requesting info from "https://192.0.2.10: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.10:6443"
[discovery] Successfully established connection with API Server "192.0.2.10:6443"
[discovery] Cluster info signature and contents are valid 
and TLS certificate validates against pinned roots, will use API Server "192.0.2.10:6443"
[discovery] Successfully established connection with API Server "192.0.2.10: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.10:6443)を、APIサーバー(マスター・ノード)で使用されるIPアドレスとポートに置き換えます。デフォルト・ポートは6443であることに注意してください。

--token値(8tipwo.tst0nvf7wcaqjcj0)を、マスター・ノードの有効なトークンに置き換えます。この情報がない場合は、マスター・ノードで次のコマンドを実行して、この情報を取得します。 

# kubeadm token list
TOKEN                    TTL  EXPIRES             USAGES           DESCRIPTION        EXTRA GROUPS
8tipwo.tst0nvf7wcaqjcj0  22h  2018-12-11          authentication,  <none>             system:
                              T03:32:44-08:00     signing                             bootstrappers:
                                                                                      kubeadm:
                                                                                      default-node-token

デフォルトでは、トークンは24時間後に期限切れになります。現在のトークンが期限切れになった後にノードをクラスタに結合する場合は、マスター・ノードで次のコマンドを実行して、新しいトークンを作成できます。 

# kubeadm token create
e05e12.3c1096c88cc11720

トークンの作成時に--ttlオプションを使用して、トークンの有効期限を明示的に設定できます。このオプションでは、現在の時間を基準としてトークンの有効期限を設定します。通常、この値は秒単位で設定されますが、その他の単位も指定できます。たとえば、現在の時間から15m (15分)、または現在の時間から1h (1時間)のトークン有効期限を設定できます。0の値は、トークンが期限切れにならないことを意味しますが、この値はお薦めしません。

--discovery-token-ca-cert-hash値(f2a5b22b658683c3634459c8e7617c9d6c080c72dd149f3eb903445efe9d8346)を、マスター・ノードのトークン証明書の署名に使用される正しいSHA256 CA証明書ハッシュに置き換えます。この情報がない場合は、マスター・ノードで次のコマンド・チェーンを実行して、この情報を取得します。 

#  openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \
   openssl dgst -sha256 -hex | sed 's/^.* //'
f2a5b22b658683c3634459c8e7617c9d6c080c72dd149f3eb903445efe9d8346

kubeadm-setup.shスクリプトにより、ワーカー・ノードの設定前に、ホストがすべての要件を満たしているかどうかがチェックされます。要件が満たされない場合は、推奨される修正とともにエラー・メッセージが表示されます。スクリプトを再度実行する前に、エラーを修正する必要があります。

kubelet systemdサービスは、ワーカー・ノードがブート時に常に起動されるように、ホスト上で自動的に有効になります。

kubeadm-setup.sh joinコマンドが完了したら、マスター・ノードでワーカー・ノードにクラスタが結合されていることを確認します。 

$ kubectl get nodes
NAME                  STATUS    ROLES   AGE       VERSION
master.example.com    Ready     master  1h        v1.12.7+1.1.2.el7
worker1.example.com   Ready     <none>  1h        v1.12.7+1.1.2.el7

このコマンドの出力には、クラスタ内のすべてのノードとそのステータスのリストが表示されます。

2.5 1.1.9から1.1.12へのアップグレード

次の手順は、Kubernetesと使用するOracle Linux Container Services 1.1.9からバージョン1.1.12へのメジャー・パッケージ・アップグレード専用です。

警告

ここで説明するアップグレード・プロセスは、既存のホスト上の指定されたアップグレードパスにのみ適用されます。

オラクル社は、kubeadm-uprade.shスクリプトを使用した、小規模なエラータ・リリース間の既存のクラスタのアップグレードをサポートしていません。かわりに、第2.6項「エラータ・リリースへの更新」で説明されている、kubeadm-setup.shスクリプトを使用する必要があります。

これらの手順は、UEK R4からブートされるホスト上で機能しますが、今後のアップグレードを容易にするために、現在UEK R4が実行されているホストをUEK R5 (KubeDNSは非推奨になる)を使用するようアップグレードすることをお薦めします。

アップグレード・プロセスでは、まずクラスタ内のマスター・ノードをアップグレードしてから、各ワーカー・ノードを更新する必要があります。マスター・ノードのアップグレードは、前提条件のチェック、検証および再構成が自動化されるようにスクリプト化されています。アップグレードする前に、クラスタのバックアップ・ファイルを作成することをお薦めします。このプロセスの詳細は、第2.5.1項「マスター・ノードの1.1.9から1.1.12へのアップグレード」を参照してください。

マスター・ノードのアップグレード後、第2.5.2項「ワーカー・ノードの1.1.9から1.1.12へのアップグレード」の説明に従って、各ワーカー・ノードをアップグレードできます。

クラスタのアップグレードが完了したら、クラスタで実行されていたすべてのアプリケーションを再起動または再デプロイする必要があります。

重要

オラクル社は、プレビュー・リリースから安定したサポート対象リリースへのアップグレードをサポートしていません。

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

2.5.1 マスター・ノードの1.1.9から1.1.12へのアップグレード

ワーカー・ノードをアップグレードする前に、クラスタ内のマスター・ノードをアップグレードする必要があります。マスター・ノードでkubeadm-upgrade.sh upgradeコマンドを使用して、必要なバックアップ・ファイルを作成し、クラスタを準備およびアップグレードするために必要なステップを完了します。

重要

更新操作を実行する前に、クラスタのバックアップ・ファイルを現在のバージョンで作成します。kubeadmパッケージを更新すると、作成するバックアップ・ファイルには下位互換性がなくなります。Kubernetesと使用するOracle Linux Container Servicesの以前のバージョンに戻す場合、リストア操作でバックアップ・ファイルが正常にロードできないことがあります。詳細は、第4.3項「クラスタのバックアップおよびリストア」を参照してください。

1.1.9から1.1.12への失敗したアップグレードからリストアする際に、kubeadm-setupによって生成されたバックアップを使用しないでください。kubeadm-upgradeツールにより、この項の後半で説明するように、独自のバックアップおよびリストアの個別のメカニズムが提供されます。

マスター・ノードの1.1.12へのアップグレード

  1. エラータ・アップグレードとは異なり、kubeadmパッケージを手動で更新する必要はありませんが、kubeadm-upgradeパッケージをインストールする必要はあります。 

    # yum install kubeadm-upgrade

  2. Oracle Container Registryを使用してイメージを取得する場合は、ログインします。

    第2.2.5項「Oracle Container Registryの要件」の手順に従います。Oracle Container Registryでイメージが更新された場合、アップグレードを実行するには、Oracle標準の条件および制約を再度受け入れることが必要になる可能性があります。Oracle Container Registryミラーのいずれかを使用する場合の詳細は、第2.2.5.1項「Oracle Container Registryミラーの使用方法」を参照してください。

    ローカル・レジストリを構成している場合は、適切なレジストリを指すようにKUBE_REPO_PREFIX環境変数を設定することが必要になる可能性があります。アップグレード先のバージョンの最新のイメージを使用して、ローカル・レジストリを更新することが必要になる場合もあります。詳細は、第2.2.5.2項「オプションのローカル・レジストリの設定」を参照してください。

  3. 第2.2.7項「ファイアウォールとiptablesの要件」の説明に従って、新しいファイアウォール・ポートが開いていることを確認します。

  4. アップグレード前のバックアップ・ファイルを作成します。エラータ・リリース・アップグレードの手順とは異なり、バックアップファイルはkubeadm-upgrade.sh backupを使用して生成されます。アップグレードが正常に完了しない場合、バックアップは、アップグレード前のクラスタの構成に戻すことができます。 

    # kubeadm-setup.sh stop
Stopping kubelet now ...
Stopping containers now ...

# kubeadm-upgrade.sh backup /backups
-- Running upgrade script---
Backing up cluster
Creating backup at directory /backups ...
Using 3.1.11
Checking if container-registry.oracle.com/kubernetes/etcd-amd64:3.1.11 is available
dc9ed9408e82dbd9d925c4d660206f9c60dce98c150cb32517284a6ef764f59d  
/var/run/kubeadm/backup/etcd-backup-1546953894.tar
aa2dad1ba2c2ec486d30fe0a15b29566b257474429d79889472fd79128489ae0  
/var/run/kubeadm/backup/k8s-master-0-1546953894.tar
Backup is successfully stored at /backups/master-backup-v1.9.11-0-1546953894.tar ...
You can restart your cluster now by doing: 
# kubeadm-setup.sh restart
Storing meta-data to backup file master-backup-v1.9.11-0-1546953894.tar
.version-info
Backup creation successful :)

# kubeadm-setup.sh restart
Restarting containers now ...
Detected node is master ...
Checking if env is ready ...
Checking whether docker can pull busybox image ...
Checking access to container-registry.oracle.com/kubernetes ...
Trying to pull repository container-registry.oracle.com/kubernetes/pause ... 
3.1: Pulling from container-registry.oracle.com/kubernetes/pause
Digest: sha256:802ef89b9eb7e874a76e1cfd79ed990b63b0b84a05cfa09f0293379ac0261b49
Status: Image is up to date for container-registry.oracle.com/kubernetes/pause:3.1
Checking firewalld settings ...
Checking iptables default rule ...
Checking br_netfilter module ...
Checking sysctl variables ...
Restarting kubelet ...
Waiting for node to restart ...
.......+..............
Master node restarted. Complete synchronization between nodes may take a few minutes.

  5. マスター・ノードで、rootとしてkubeadm-upgrade.sh upgradeコマンドを実行します。 

    # kubeadm-upgrade.sh upgrade
-- Running upgrade script---
Number of cpu present in this system 2
Total memory on this system: 7710MB
Space available on the mount point /var/lib/docker: 44GB
Space available on the mount point /var/lib/kubelet: 44GB
kubeadm version 1.9
kubectl version 1.9
kubelet version 1.9
ol7_addons repo enabled
[WARNING] This action will upgrade this node to latest version
[WARNING] The cluster will be upgraded through intermediate 
versions which are unsupported
[WARNING] You must take backup before upgrading the cluster as upgrade may fail
  Please select 1 (continue) or 2 (abort) :
1) continue
2) abort
#? 1

Upgrading master node
Checking access to container-registry.oracle.com/kubernetes for update
Trying to pull repository container-registry.oracle.com/kubernetes/kube-proxy-amd64
v1.10.5: Pulling from container-registry.oracle.com/kubernetes/kube-proxy-amd64
Digest: sha256:4739e1154818a95786bc94d44e1cb4f493083d1983e98087c8a8279e616582f1
Status: Image is up to date for 
container-registry.oracle.com/kubernetes/kube-proxy-amd64:v1.10.5
Checking access to container-registry.oracle.com/kubernetes for update
Trying to pull repository container-registry.oracle.com/kubernetes/kube-proxy-amd64
v1.11.3: Pulling from container-registry.oracle.com/kubernetes/kube-proxy-amd64
Digest: sha256:2783b4d4689da3210d2a915a8ee60905bf53841be4d52ffbf56cc811c61d5728
Status: Image is up to date for 
container-registry.oracle.com/kubernetes/kube-proxy-amd64:v1.11.3
Checking access to container-registry.oracle.com/kubernetes for update
Trying to pull repository container-registry.oracle.com/kubernetes/kube-proxy ...
v1.12.7: Pulling from Pulling from container-registry.oracle.com/kubernetes/kube-proxy
Digest: sha256:f4f9e7b70a65f4f7d751da9b97c7536b21a7ac2b301155b0685778fc83d5510f
Status: Image is up to date for Pulling from 
container-registry.oracle.com/kubernetes/kube-proxy:v1.12.7
Loaded plugins: langpacks, ulninfo
Resolving Dependencies
--> Running transaction check
---> Package kubeadm.x86_64 0:1.9.11-2.1.1.el7 will be updated
---> Package kubeadm.x86_64 0:1.10.5-2.0.2.el7 will be an update
---> Package kubectl.x86_64 0:1.9.11-2.1.1.el7 will be updated
---> Package kubectl.x86_64 0:1.10.5-2.0.2.el7 will be an update
---> Package kubelet.x86_64 0:1.9.11-2.1.1.el7 will be updated
---> Package kubelet.x86_64 0:1.10.5-2.0.2.el7 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

================================================================
 Package   Arch          Version          Repository       Size
================================================================
Updating:
 kubeadm   x86_64     1.10.5-2.0.2.el7    ol7_addons       17 M
 kubectl   x86_64     1.10.5-2.0.2.el7    ol7_addons       7.6 M
 kubelet   x86_64     1.10.5-2.0.2.el7    ol7_addons       17 M

Transaction Summary
=================================================================
Upgrade  3 Packages

Total download size: 42 M
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
--------------------------------------------------------------------------------
Total                                               49 MB/s |  42 MB  00:00
Running transaction check
Running transaction test
Transaction test succeeded   
Running transaction
  Updating   : kubelet-1.10.5-2.0.2.el7.x86_64                              1/6
  Updating   : kubectl-1.10.5-2.0.2.el7.x86_64                              2/6
  Updating   : kubeadm-1.10.5-2.0.2.el7.x86_64                              3/6
  Cleanup    : kubeadm-1.9.11-2.1.1.el7.x86_64                              4/6
  Cleanup    : kubectl-1.9.11-2.1.1.el7.x86_64                              5/6
  Cleanup    : kubelet-1.9.11-2.1.1.el7.x86_64                              6/6
  Verifying  : kubectl-1.10.5-2.0.2.el7.x86_64                              1/6
  Verifying  : kubelet-1.10.5-2.0.2.el7.x86_64                              2/6
  Verifying  : kubeadm-1.10.5-2.0.2.el7.x86_64                              3/6
  Verifying  : kubectl-1.9.11-2.1.1.el7.x86_64                              4/6
  Verifying  : kubeadm-1.9.11-2.1.1.el7.x86_64                              5/6
  Verifying  : kubelet-1.9.11-2.1.1.el7.x86_64                              6/6

Updated:
  kubeadm.x86_64 0:1.10.5-2.0.2.el7      kubectl.x86_64 0:1.10.5-2.0.2.el7
  kubelet.x86_64 0:1.10.5-2.0.2.el7

Complete!
Upgrading pre-requisite
Checking whether api-server is using image lower than 1.9
Upgrading pre-requisite done 
Checking cluster health ...  
....
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration options from a file: 
/var/run/kubeadm/kubeadm-cfg
[upgrade/version] You have chosen to change the cluster version to "v1.10.5"
[upgrade/versions] Cluster version: v1.9.11+2.1.1.el7
[upgrade/versions] kubeadm version: v1.10.5+2.0.2.el7
[upgrade/prepull] Will prepull images for 
components [kube-apiserver kube-controller-manager kube-scheduler]
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.10.5"...
Static pod: kube-apiserver-master.example.com hash: 
3b6cc643053ae0164a687e53fbcf4eb7
Static pod: kube-controller-manager-master.example.com hash: 
78b0313a30bbf65cf169686001a2c093
Static pod: kube-scheduler-master.example.com hash: 
8fa7d39f0a3246bb39baf3712702214a
[upgrade/etcd] Upgrading to TLS for etcd
Static pod: etcd-master.example.com hash: 196164156fbbd2ef7daaf8c6a0ec6379
[etcd] Wrote Static Pod manifest for a local etcd instance 
to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests139181353/etcd.yaml"
[certificates] Generated etcd/ca certificate and key.
[certificates] Generated etcd/server certificate and key.
[certificates] etcd/server serving cert is signed for DNS names [localhost] 
and IPs [127.0.0.1]
[certificates] Generated etcd/peer certificate and key.
[certificates] etcd/peer serving cert is signed for DNS 
names [master.example.com] and IPs [19.0.2.10]
[certificates] Generated etcd/healthcheck-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" 
and backed up old manifest 
to "/etc/kubernetes/tmp/kubeadm-backup-manifests154060916/etcd.yaml"
[upgrade/staticpods] Not waiting for pod-hash change for component "etcd"
[upgrade/etcd] Waiting for etcd to become available
[util/etcd] Waiting 30s for initial delay
[util/etcd] Attempting to see if all cluster endpoints are available 1/10
[util/etcd] Attempt failed with error: dial tcp [::1]:2379: 
getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to see if all cluster endpoints are available 2/10
[util/etcd] Attempt failed with error: dial tcp [::1]:2379: 
getsockopt: connection refused
[util/etcd] Waiting 15s until next retry
[util/etcd] Attempting to see if all cluster endpoints are available 3/10
[upgrade/staticpods] Writing new Static Pod manifests 
to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests139181353"
[controlplane] Wrote Static Pod manifest for component kube-apiserver 
to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests139181353/kube-apiserver.yaml"
[controlplane] Wrote Static Pod manifest for component kube-controller-manager 
to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests139181353/kube-controller-manager.yaml"
[controlplane] Wrote Static Pod manifest for component kube-scheduler 
to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests139181353/kube-scheduler.yaml"
[upgrade/staticpods] The etcd manifest will be restored if 
component "kube-apiserver" fails to upgrade
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Generated apiserver-etcd-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" 
and backed up old manifest 
to "/etc/kubernetes/tmp/kubeadm-backup-manifests154060916/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
Static pod: kube-apiserver-master.example.com hash: 3b6cc643053ae0164a687e53fbcf4eb7
Static pod: kube-apiserver-master.example.com hash: f7c7c2a1693f48bc6146119961c47cad
[apiclient] Found 1 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-manifests154060916/kube-controller-manager.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
Static pod: kube-controller-manager-master.example.com hash: 
78b0313a30bbf65cf169686001a2c093
Static pod: kube-controller-manager-master.example.com hash: 
3fffc11595801c3777e45ff96ce75444
[apiclient] Found 1 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-manifests154060916/kube-scheduler.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
Static pod: kube-scheduler-master.example.com hash: 8fa7d39f0a3246bb39baf3712702214a
Static pod: kube-scheduler-master.example.com hash: c191e26d0faa00981a2f0d6f1f0d7e5f
[apiclient] Found 1 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
[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: kube-dns
[addons] Applied essential addon: kube-proxy

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

[upgrade/kubelet] Now that your control plane is upgraded, 
please proceed with upgrading your kubelets in turn.
Upgrading kubeadm to 1.11.3 version
Loaded plugins: langpacks, ulninfo
Resolving Dependencies
--> Running transaction check
---> Package kubeadm.x86_64 0:1.10.5-2.0.2.el7 will be updated
---> Package kubeadm.x86_64 0:1.11.3-2.0.2.el7 will be an update
--> Finished Dependency Resolution

Dependencies Resolved


================================================================
 Package   Arch          Version          Repository       Size
================================================================
Updating:
 kubeadm   x86_64    1.11.3-2.0.2.el7     ol7_addons      7.6 M

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

Total download size: 7.6 M   
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
Running transaction check
Running transaction test
Transaction test succeeded   
Running transaction
  Updating   : kubeadm-1.11.3-2.0.2.el7.x86_64                              1/2
  Cleanup    : kubeadm-1.10.5-2.0.2.el7.x86_64                              2/2
  Verifying  : kubeadm-1.11.3-2.0.2.el7.x86_64                              1/2
  Verifying  : kubeadm-1.10.5-2.0.2.el7.x86_64                              2/2

Updated:
  kubeadm.x86_64 0:1.11.3-2.0.2.el7

Complete!
Upgrading pre-requisite
Checking whether api-server is using image lower than 1.9
Upgrading pre-requisite done 
Checking cluster health ...  
....................................................................................
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration options from a file: /var/run/kubeadm/kubeadm-cfg
[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.11.3"
[upgrade/versions] Cluster version: v1.10.5+2.0.2.el7
[upgrade/versions] kubeadm version: v1.11.3+2.0.2.el7
[upgrade/version] Found 1 potential version compatibility errors 
but skipping since the --force flag is set:

        - There are kubelets in this cluster that are too old 
          that have these versions [v1.9.11+2.1.1.el7]
[upgrade/prepull] Will prepull images 
for components [kube-apiserver kube-controller-manager kube-scheduler etcd]
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.11.3"...
Static pod: kube-apiserver-master.example.com hash: f7c7c2a1693f48bc6146119961c47cad
Static pod: kube-controller-manager-master.example.com hash: 
3fffc11595801c3777e45ff96ce75444
Static pod: kube-scheduler-master.example.com hash: c191e26d0faa00981a2f0d6f1f0d7e5f
Static pod: etcd-master.example.com hash: 6ecccbc01b0cd9daa0705a1396ef38e5
[etcd] Wrote Static Pod manifest for a local etcd instance 
to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests842182537/etcd.yaml"
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Using the existing etcd/server certificate and key.
[certificates] Using the existing etcd/peer certificate and key.
[certificates] Using the existing etcd/healthcheck-client certificate and key.
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/etcd.yaml" 
and backed up old manifest 
to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2019-01-09-07-25-48/etcd.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
Static pod: etcd-master.example.com hash: 6ecccbc01b0cd9daa0705a1396ef38e5
Static pod: etcd-master.example.com hash: 6ecccbc01b0cd9daa0705a1396ef38e5
Static pod: etcd-master.example.com hash: 6ecccbc01b0cd9daa0705a1396ef38e5
Static pod: etcd-master.example.com hash: 560672e3081cf0ff6a30ac1f943240eb
[apiclient] Found 1 Pods for label selector component=etcd
[upgrade/staticpods] Component "etcd" upgraded successfully!
[upgrade/etcd] Waiting for etcd to become available
[util/etcd] Waiting 0s for initial delay
[util/etcd] Attempting to see if all cluster endpoints are available 1/10
[upgrade/staticpods] Writing new Static Pod manifests 
to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests842182537"
[controlplane] wrote Static Pod manifest for component kube-apiserver 
to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests842182537/kube-apiserver.yaml"
[controlplane] wrote Static Pod manifest for component kube-controller-manager 
to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests842182537/kube-controller-manager.yaml"
[controlplane] wrote Static Pod manifest for component kube-scheduler 
to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests842182537/kube-scheduler.yaml"
[certificates] Using the existing etcd/ca certificate and key.
[certificates] Using the existing apiserver-etcd-client certificate and key.
[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-01-09-07-25-48/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
Static pod: kube-apiserver-master.example.com hash: f7c7c2a1693f48bc6146119961c47cad
Static pod: kube-apiserver-master.example.com hash: f7c7c2a1693f48bc6146119961c47cad
Static pod: kube-apiserver-master.example.com hash: f7c7c2a1693f48bc6146119961c47cad
Static pod: kube-apiserver-master.example.com hash: 9eefcb38114108702fad91f927799c04
[apiclient] Found 1 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-01-09-07-25-48/
kube-controller-manager.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
Static pod: kube-controller-manager-master.example.com hash: 
3fffc11595801c3777e45ff96ce75444
Static pod: kube-controller-manager-master.example.com hash: 
32b0f7233137a5c4879bda1067f36f8a
[apiclient] Found 1 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-01-09-07-25-48/kube-scheduler.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
Static pod: kube-scheduler-master.example.com hash: c191e26d0faa00981a2f0d6f1f0d7e5f
Static pod: kube-scheduler-master.example.com hash: b589c7f85a86056631f252695c20358b
[apiclient] Found 1 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.11" in namespace kube-system 
with the configuration for the kubelets in the cluster
[kubelet] Downloading configuration for the kubelet from 
the "kubelet-config-1.11" 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"
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" 
to the Node API object "master.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: kube-dns
[addons] Applied essential addon: kube-proxy

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

[upgrade/kubelet] Now that your control plane is upgraded, please proceed with 
upgrading your kubelets if you haven't already done so.
Upgrading kubelet and kubectl now ...
Checking kubelet and kubectl RPM ...
[INFO] yum install -y kubelet-1.11.3-2.0.2.el7.x86_64
Loaded plugins: langpacks, ulninfo
Resolving Dependencies
--> Running transaction check
---> Package kubelet.x86_64 0:1.10.5-2.0.2.el7 will be updated
---> Package kubelet.x86_64 0:1.11.3-2.0.2.el7 will be an update
--> Finished Dependency Resolution

Dependencies Resolved
===================================================================================
 Package        Arch          Version                   Repository           Size
===================================================================================
Updating:
 kubelet        x86_64      1.11.3-2.0.2.el7             ol7_addons           18 M

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

Total download size: 18 M
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
kubelet-1.11.3-2.0.2.el7.x86_64.rpm                           |  18 MB  00:00:00
Running transaction check
Running transaction test
Transaction test succeeded   
Running transaction
  Updating   : kubelet-1.11.3-2.0.2.el7.x86_64                1/2
  Cleanup    : kubelet-1.10.5-2.0.2.el7.x86_64                2/2
  Verifying  : kubelet-1.11.3-2.0.2.el7.x86_64                1/2
  Verifying  : kubelet-1.10.5-2.0.2.el7.x86_64                2/2

Updated:
  kubelet.x86_64 0:1.11.3-2.0.2.el7

Complete!
[INFO] yum install -y kubectl-1.11.3-2.0.2.el7.x86_64
Loaded plugins: langpacks, ulninfo
Resolving Dependencies
--> Running transaction check
---> Package kubectl.x86_64 0:1.10.5-2.0.2.el7 will be updated
---> Package kubectl.x86_64 0:1.11.3-2.0.2.el7 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

===================================================================================
 Package        Arch          Version                   Repository           Size
===================================================================================
Updating:
 kubectl       x86_64     1.11.3-2.0.2.el7               ol7_addons          7.6 M

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

Total download size: 7.6 M   
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
kubectl-1.11.3-2.0.2.el7.x86_64.rpm                          | 7.6 MB  00:00:00
Running transaction check
Running transaction test
Transaction test succeeded   
Running transaction
  Updating   : kubectl-1.11.3-2.0.2.el7.x86_64                1/2
  Cleanup    : kubectl-1.10.5-2.0.2.el7.x86_64                2/2
  Verifying  : kubectl-1.11.3-2.0.2.el7.x86_64                1/2
  Verifying  : kubectl-1.10.5-2.0.2.el7.x86_64                2/2

Updated:
  kubectl.x86_64 0:1.11.3-2.0.2.el7

Complete!
Upgrading kubelet and kubectl to 1.11.3 version
Loaded plugins: langpacks, ulninfo
Package kubelet-1.11.3-2.0.2.el7.x86_64 already installed and latest version
Package kubectl-1.11.3-2.0.2.el7.x86_64 already installed and latest version
Nothing to do
Upgrading kubeadm to 1.12.7-1.1.2.el7 version
Loaded plugins: langpacks, ulninfo
Resolving Dependencies
--> Running transaction check
---> Package kubeadm.x86_64 0:1.11.3-2.0.2.el7 will be updated
---> Package kubeadm.x86_64 0:1.12.7-1.1.2.el7 will be an update
--> Finished Dependency Resolution

Dependencies Resolved


===================================================================================
 Package        Arch          Version                   Repository           Size
===================================================================================
 kubeadm        x86_64      1.12.7-1.1.2.el7            ol7_addons          7.3 M

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

Total download size: 7.3 M   
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
kubeadm-1.12.7-1.1.2.el7.x86_64.rpm                               | 7.3 MB  00:00:00
Running transaction check
Running transaction test
Transaction test succeeded   
Running transaction
  Updating   : kubeadm-1.12.7-1.1.2.el7.x86_64                    1/2
  Cleanup    : kubeadm-1.11.3-2.0.2.el7.x86_64                    2/2
  Verifying  : kubeadm-1.12.7-1.1.2.el7.x86_64                    1/2
  Verifying  : kubeadm-1.11.3-2.0.2.el7.x86_64                    2/2

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

Complete!
Upgrading pre-requisite
Checking whether api-server is using image lower than 1.9
Upgrading pre-requisite done 
Checking cluster health ...  
...........................................................................
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration options from a file: /var/run/kubeadm/kubeadm-cfg
[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.5"
[upgrade/versions] Cluster version: v1.11.3+2.0.2.el7
[upgrade/versions] kubeadm version: v1.12.7+1.1.2.el7
[upgrade/version] Found 1 potential version compatibility errors 
but skipping since the --force flag is set:

        - There are kubelets in this cluster that are too old that have 
          these versions [v1.9.11+2.1.1.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-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 1 Pods for label selector k8s-app=upgrade-prepull-kube-apiserver
[apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler
[apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-etcd
[upgrade/prepull] Prepulled image for component kube-apiserver.
[upgrade/prepull] Prepulled image for component kube-controller-manager.
[upgrade/prepull] Prepulled image for component etcd.
[upgrade/prepull] Prepulled image for component kube-scheduler.
[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.5"...
Static pod: kube-apiserver-master.example.com hash: 7c19bbee52e8a857c9e75551139951b7
Static pod: kube-controller-manager-master.example.com hash: 
0221796c266be3d6f237a7256da5fa36
Static pod: kube-scheduler-master.example.com hash: e0549b9041665ae07cfacdaf337ab1e0
Static pod: etcd-master.example.com hash: 7a68f8a24bf031e2027cc6d528ce6efe
[etcd] Wrote Static Pod manifest for a local etcd instance 
to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests665746710/etcd.yaml"
[upgrade/staticpods] Moved new manifest 
to "/etc/kubernetes/manifests/etcd.yaml" and backed up old manifest 
to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2019-01-09-07-34-07/etcd.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: etcd-master.example.com hash: 7a68f8a24bf031e2027cc6d528ce6efe
Static pod: etcd-master.example.com hash: 7a68f8a24bf031e2027cc6d528ce6efe
Static pod: etcd-master.example.com hash: 7eab06d7296bf87cff84cb56f26d13e6
[apiclient] Found 1 Pods for label selector component=etcd
[upgrade/staticpods] Component "etcd" upgraded successfully!
[upgrade/etcd] Waiting for etcd to become available
[util/etcd] Waiting 0s for initial delay
[util/etcd] Attempting to see if all cluster endpoints are available 1/10
[upgrade/staticpods] Writing new Static Pod manifests 
to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests665746710"
[controlplane] wrote Static Pod manifest for component kube-apiserver 
to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests665746710/kube-apiserver.yaml"
[controlplane] wrote Static Pod manifest for component kube-controller-manager 
to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests665746710/kube-controller-manager.yaml"
[controlplane] wrote Static Pod manifest for component kube-scheduler 
to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests665746710/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-01-09-07-34-07/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-master.example.com hash: 7c19bbee52e8a857c9e75551139951b7
Static pod: kube-apiserver-master.example.com hash: 7c19bbee52e8a857c9e75551139951b7
Static pod: kube-apiserver-master.example.com hash: 7c19bbee52e8a857c9e75551139951b7
Static pod: kube-apiserver-master.example.com hash: 7c19bbee52e8a857c9e75551139951b7
Static pod: kube-apiserver-master.example.com hash: 5c6ceef93d0a8c04d331d6ea6da4b6a7
[apiclient] Found 1 Pods for label selector component=kube-apiserver
[apiclient] Found 1 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 "k8s-m1.us.oracle.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: kube-dns
[addons] Applied essential addon: kube-proxy

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

[upgrade/kubelet] Now that your control plane is upgraded, 
please proceed with upgrading your kubelets if you haven't already done so.
Upgrading kubelet and kubectl now ...
Checking kubelet and kubectl RPM ...
[INFO] yum install -y kubelet-1.12.7-1.1.2.el7.x86_64
Loaded plugins: langpacks, ulninfo
Resolving Dependencies
--> Running transaction check
---> Package kubelet.x86_64 0:1.11.3-2.0.2.el7 will be updated
---> Package kubelet.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:
 kubelet       x86_64      1.12.7-1.1.2.el7             ol7_addons           19 M

Transaction Summary
====================================================================================

Upgrade  1 Package

Total download size: 19 M
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
kubelet-1.12.7-1.1.2.el7.x86_64.rpm                                        
Running transaction check
Running transaction test
Transaction test succeeded   
Running transaction
  Updating   : kubelet-1.12.7-1.1.2.el7.x86_64                        1/2
  Cleanup    : kubelet-1.11.3-2.0.2.el7.x86_64                        2/2
  Verifying  : kubelet-1.12.7-1.1.2.el7.x86_64                        1/2
  Verifying  : kubelet-1.11.3-2.0.2.el7.x86_64                        2/2

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

Complete!
[INFO] yum install -y kubectl-1.12.7-1.1.2.el7.x86_64
Loaded plugins: langpacks, ulninfo
Resolving Dependencies
--> Running transaction check
---> Package kubectl.x86_64 0:1.11.3-2.0.2.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.
kubectl-1.12.7-1.1.2.el7.x86_64.rpm                        | 7.7 MB  00:00:00
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.11.3-2.0.2.el7.x86_64              2/2
  Verifying  : kubectl-1.12.7-1.1.2.el7.x86_64              1/2
  Verifying  : kubectl-1.11.3-2.0.2.el7.x86_64              2/2

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

Complete!
[INSTALLING DASHBOARD NOW]   

Installing kubernetes-dashboard ...

Kubernetes version: v1.12.7 and dashboard yaml file: 
/usr/local/share/kubeadm/kubernetes-dashboard-self-certs.yaml
The connection to the server 10.147.25.195:6443 was refused - 
did you specify the right host or port?
Restarting kubectl-proxy.service ...
[INFO] Upgrading master node done successfully
[INFO] Flannel is not upgraded yet. Please run 
'kubeadm-upgrade.sh upgrade --flannel' to upgrade flannel
[INFO] Dashboard is not upgraded yet. Please run 
'kubeadm-upgrade.sh upgrade --dashboard' to upgrade dashboard

  6. Kubernetesと使用するOracle Linux Container Services 1.1.12が依存するflannelサービスは、特殊なアップグレード・スクリプトによって自動的にはアップグレードされないため、個別にアップグレードするようにしてください。次に例を示します。 

    # kubeadm-setup.sh upgrade --flannel
Trying to pull repository container-registry.oracle.com/kubernetes/flannel ... 
v0.10.0: Pulling from container-registry.oracle.com/kubernetes/flannel
Digest: sha256:da1f7af813d6b6123c9a240b3e7f9b58bc7b50d9939148aa08c7ba8253e0c312
Status: Image is up to date for container-registry.oracle.com/kubernetes/flannel:v0.10.0
kube-flannel-ds-85clc kube-flannel-ds-x9grm
clusterrole.rbac.authorization.k8s.io "flannel" deleted
clusterrolebinding.rbac.authorization.k8s.io "flannel" deleted
serviceaccount "flannel" deleted
configmap "kube-flannel-cfg" deleted
daemonset.extensions "kube-flannel-ds" deleted
pod "kube-flannel-ds-85clc" deleted
pod "kube-flannel-ds-x9grm" deleted
NAME                                        READY   STATUS    RESTARTS   AGE
etcd-master.example.com                      1/1     Running   0          11m
kube-apiserver-master.example.com            1/1     Running   0          11m
kube-controller-manager-master.example.com   1/1     Running   0          11m
kube-dns-554d547449-hhl6p                    3/3     Running   0          12m
kube-proxy-bc7ht                             1/1     Running   0          12m
kube-proxy-jd8gh                             1/1     Running   0          12m
kube-scheduler-master.example.com            1/1     Running   0          11m
kubernetes-dashboard-64c8c8b9dd-c9wfl        1/1     Running   1          41m
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.extensions/kube-flannel-ds created

  7. Kubernetesと使用するOracle Linux Container Servicesダッシュボード・サービスも、個別に1.1.12にアップグレードする必要があります。 

    # kubeadm-upgrade.sh upgrade --dashboard
Upgrading dashboard
secret "kubernetes-dashboard-certs" deleted
serviceaccount "kubernetes-dashboard" deleted
role.rbac.authorization.k8s.io "kubernetes-dashboard-minimal" deleted
rolebinding.rbac.authorization.k8s.io "kubernetes-dashboard-minimal" deleted
deployment.apps "kubernetes-dashboard" deleted
service "kubernetes-dashboard" deleted

Installing kubernetes-dashboard ...

Kubernetes version: v1.12.7 and dashboard yaml file: 
/usr/local/share/kubeadm/kubernetes-dashboard-self-certs.yaml
secret/kubernetes-dashboard-certs created
serviceaccount/kubernetes-dashboard created
role.rbac.authorization.k8s.io/kubernetes-dashboard-minimal created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard-minimal created
deployment.apps/kubernetes-dashboard created
service/kubernetes-dashboard created
Restarting kubectl-proxy.service ...

  8. マスター・ノードのアップグレードが失敗した場合は、次のようにロールバックします。 

    # kubeadm-upgrade.sh restore /backups/master-backup-v1.9.11-0-1546953894.tar
-- Running upgrade script---
Restoring the cluster
Loaded plugins: langpacks, ulninfo
Nothing to do
Checking sha256sum of the backup files ...
/var/run/kubeadm/backup/etcd-backup-1546953894.tar: OK
/var/run/kubeadm/backup/k8s-master-0-1546953894.tar: OK
Restoring backup from /backups/master-backup-v1.9.11-0-1546953894.tar ...
Using 3.1.11
etcd cluster is healthy ...
Cleaning up etcd container ...
ab9e7a31a721c2b9690047ac3445beeb2c518dd60da81da2a396f250f089e82e
ab9e7a31a721c2b9690047ac3445beeb2c518dd60da81da2a396f250f089e82e
Restore successful ...
You can restart your cluster now by doing: 
# kubeadm-setup.sh restart
Restore successful :)

  9. スクリプトが正常に完了した場合は、kubeadm-setup.sh backupを使用して、新しいKubernetesを使用するOracle Linux Container Services 1.1.12で、バックアップを新規に作成します。

    第4.3項「クラスタのバックアップおよびリストア」を参照してください。

/var/log/kubeadm-upgradeで完全なアップグレード・ログを参照できます。マスター・ノードのアップグレードが完了したら、各ワーカー・ノードで、Kubernetesと使用するOracle Linux Container Servicesのパッケージをアップグレードできます。

2.5.2 ワーカー・ノードの1.1.9から1.1.12へのアップグレード

第2.5.1項「マスター・ノードの1.1.9から1.1.12へのアップグレード」の説明に従って、マスター・ノードのアップグレード・プロセスが完了した後にのみ、ワーカー・ノードをアップグレードします。

重要

ワーカー・ノードのアップグレードを完了するには、いくつかの手動ステップを実行する必要があります。これらのステップでは、アップグレード前にノードをドレインし、クラスタで、アップグレード中にノード上のポッドがスケジュールまたは開始されないようにします。ドレイン・プロセスにより、実行中のすべてのポッドがノードから削除されます。ローカル記憶域が構成されている場合は、ドレイン・プロセスでエラーが発生するため、それを受けてローカル・データをバックアップする必要があるかどうかを判断できます。

アップグレードが完了したら、ポッドをこのノードで再開できるようにワーカー・ノードをuncordonできます。

ワーカー・ノードをアップグレードするには、次のステップを実行します。

  1. マスター・ノードから次のコマンドを実行して、ワーカー・ノードをドレインします。 

    $ kubectl drain worker1.example.com --ignore-daemonsets

    ここで、worker1.example.comは、アップグレードするワーカー・ノードのホスト名です。

    ノードにローカル記憶域が構成されている場合、ドレイン・プロセスでエラーが発生する可能性があります。次の出力例は、ローカル記憶域を使用していてドレインに失敗するノードを示しています。 

    node/worker1.example.com cordoned
error: unable to drain node "worker1.example.com", aborting command...
 
There are pending nodes to be drained:
 worker1.example.com
error: pods with local storage (use --delete-local-data to override): carts-74f4558cb8-c8p8x, 
    carts-db-7fcddfbc79-c5pkx, orders-787bf5b89f-nt9zj, orders-db-775655b675-rhlp7, 
    shipping-5bd69fb4cc-twvtf, user-db-5f9d89bbbb-7t85k

    ノードのドレインに失敗した場合は、ローカル・データをバックアップして後でリストアするなんらかの手順に従うかどうか、または続行してローカル・データを直接削除できるかどうかを決定します。バックアップ・ファイルが作成されたら、--delete-local-dataスイッチを指定してコマンドを再実行し、データを強制的に削除してノードをドレインできます。たとえば、マスター・ノードで次を実行します。 

    $ kubectl drain worker1.example.com --ignore-daemonsets --delete-local-data
node/worker1.example.com cordoned already cordoned
WARNING: Ignoring DaemonSet-managed pods: kube-flannel-ds-xrszk, kube-proxy-7g9px; 
Deleting pods with local storage: carts-74f4558cb8-g2fdw, orders-db-775655b675-gfggs, 
                                  user-db-5f9d89bbbb-k78sk
pod "user-db-5f9d89bbbb-k78sk" evicted
pod "rabbitmq-96d887875-lxm5f" evicted
pod "orders-db-775655b675-gfggs" evicted
pod "catalogue-676d4b9f7c-lvwfb" evicted
pod "payment-75f75b467f-skrbq" evicted
pod "carts-74f4558cb8-g2fdw" evicted
node "kubernetes-worker1" drained

  2. マスター・ノードで次のコマンドを実行し、ワーカー・ノードでこれ以上のスケジューリングを受け入れることができないことを確認します。 

    $ kubectl get nodes

    ドレインされたノードのステータスは、SchedulingDisabledに設定されている必要があることに注意してください。

  3. Oracle Container Registryを使用してイメージを取得する場合は、ログインします。

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

  4. ワーカー・ノードで、rootとしてkubeadm-upgrade.sh upgradeコマンドを実行します。 

    # kubeadm-upgrade.sh upgrade
-- Running upgrade script---
Number of cpu present in this system 2
Total memory on this system: 7710MB
Space available on the mount point /var/lib/docker: 44GB
Space available on the mount point /var/lib/kubelet: 44GB
kubeadm version 1.9
kubectl version 1.9
kubelet version 1.9
ol7_addons repo enabled
[WARNING] This action will upgrade this node to latest version
[WARNING] The cluster will be upgraded through intermediate versions which are unsupported
[WARNING] You must take backup before upgrading the cluster as upgrade may fail
  Please select 1 (continue) or 2 (abort) :
1) continue
2) abort
#? 1
Upgrading worker node
Updating kubeadm package
Checking access to container-registry.oracle.com/kubernetes for update
Trying to pull repository container-registry.oracle.com/kubernetes/kube-proxy ...
v1.12.5: Pulling from container-registry.oracle.com/kubernetes/kube-proxy
Digest: sha256:9eba681b56e15078cb499a3360f138cc16987cf5aea06593f77d0881af6badbe
Status: Image is up to date for container-registry.oracle.com/kubernetes/kube-proxy:v1.12.5
Upgrading kubeadm to latest version
Loaded plugins: langpacks, ulninfo
Resolving Dependencies
--> Running transaction check
---> Package kubeadm.x86_64 0:1.9.11-2.1.1.el7 will be updated
---> Package kubeadm.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:
 kubeadm   x86_64     1.12.7-1.1.2.el7   ol7_addons      7.3 M

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

Total download size: 7.3 M   
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
Running transaction check
Running transaction test
Transaction test succeeded   
Running transaction
Upgrading kubeadm forcefully from version earlier that 1.11
  Updating   : kubeadm-1.12.7-1.1.2.el7.x86_64                              1/2
  Cleanup    : kubeadm-1.9.11-2.1.1.el7.x86_64                              2/2
  Verifying  : kubeadm-1.12.7-1.1.2.el7.x86_64                              1/2
  Verifying  : kubeadm-1.9.11-2.1.1.el7.x86_64                              2/2

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

Complete!
Upgrading kubelet and kubectl now ...
Checking kubelet and kubectl RPM ...
[INFO] yum install -y kubelet-1.12.7-1.1.2.el7.x86_64
Loaded plugins: langpacks, ulninfo
Resolving Dependencies
--> Running transaction check
---> Package kubelet.x86_64 0:1.9.11-2.1.1.el7 will be updated
---> Package kubelet.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:
 kubelet    x86_64        1.12.7-1.1.2.el7              ol7_addons              19 M

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

Total download size: 19 M
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
kubelet-1.12.7-1.1.2.el7.x86_64.rpm                               |  19 MB  00:00:01
Running transaction check
Running transaction test
Transaction test succeeded   
Running transaction
  Updating   : kubelet-1.12.7-1.1.2.el7.x86_64                      1/2
  Cleanup    : kubelet-1.9.11-2.1.1.el7.x86_64                      2/2
  Verifying  : kubelet-1.12.7-1.1.2.el7.x86_64                      1/2
  Verifying  : kubelet-1.9.11-2.1.1.el7.x86_64                      2/2

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

Complete!
[INFO] yum install -y kubectl-1.12.7-1.1.2.el7.x86_64
Loaded plugins: langpacks, ulninfo
Resolving Dependencies
--> Running transaction check
---> Package kubectl.x86_64 0:1.9.11-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.
kubectl-1.12.7-1.1.2.el7.x86_64.rpm                            | 7.7 MB  00:00:00
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.9.11-2.1.1.el7.x86_64                 2/2
  Verifying  : kubectl-1.12.7-1.1.2.el7.x86_64                 1/2
  Verifying  : kubectl-1.9.11-2.1.1.el7.x86_64                 2/2

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

Complete!
[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"
[upgrade] The configuration for this node was successfully updated!
[upgrade] Now you should go ahead and upgrade the kubelet package 
using your package manager.
[WORKER NODE UPGRADED SUCCESSFULLY]

    アップグレードがノードの可用性に一時的に影響することが警告されます。アップグレードを続行することを確認する必要があります。

    kubeletサービスおよび実行中のすべてのコンテナは、アップグレード後に自動的に再起動されます。

  5. 必要に応じて新しいノードをスケジュールできるように、ワーカー・ノードをuncordonします。マスター・ノードで次を実行します。 

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

    ここで、worker1.example.comは、アップグレードしたワーカー・ノードのホスト名です。

  6. アップグレード・プロセスを終了したら、次に示すように、すべてのノードで予期されるバージョンが実行されていることを確認します。 

    $ kubectl get nodes
NAME                  STATUS    ROLES   AGE       VERSION
master.example.com    Ready     master  1h        v1.12.7+1.1.2.el7
worker1.example.com   Ready     <none>  1h        v1.12.7+1.1.2.el7
worker2.example.com   Ready     <none>  1h        v1.12.7+1.1.2.el7

2.6 エラータ・リリースへの更新

Kubernetesと使用するOracle Linux Container Servicesの更新は、Oracle Linux yumサーバーおよびULNでリリースされます。

警告

ここで説明する更新プロセスは、既存のインストールに対してマイナー更新およびセキュリティ・パッチを提供するエラータ・リリースの更新にのみ適用されます。

オラクル社は、kubeadm-setup.shスクリプトによる、Kubernetesと使用するOracle Linux Container Services 1.1.9を使用して作成された既存のクラスタの1.1.12へのアップグレードをサポートしていません。第2.5項「1.1.9から1.1.12へのアップグレード」で説明されているように、kubeadm-upgrade.shスクリプトを使用する必要があります。

これらの手順は、UEK R4からブートされるホスト上で機能しますが、今後のアップグレードを容易にするために、現在UEK R4が実行されているホストをUEK R5 (KubeDNSは非推奨になる)を使用するようアップグレードすることをお薦めします。

更新プロセスでは、まずクラスタ内のマスター・ノードを更新してから、各ワーカー・ノードを更新する必要があります。マスター・ノードの更新は、前提条件のチェック、検証および再構成が自動化されるようにスクリプト化されています。更新する前に、クラスタのバックアップ・ファイルを作成することをお薦めします。第2.6.1項「マスター・ノードの更新」を参照してください。

マスター・ノードの更新後、第2.6.2項「ワーカー・ノードの更新」の説明に従って、各ワーカー・ノードを更新できます。

重要

オラクル社は、プレビュー・リリースから安定したサポート対象リリースへのアップグレードをサポートしていません。

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

2.6.1 マスター・ノードの更新

ワーカー・ノードを更新する前に、クラスタ内のマスター・ノードを更新する必要があります。kubeadm-setup.sh upgradeコマンドをマスター・ノードで使用して、クラスタを準備および更新するために必要なステップを完了します。次のステップでは、マスター・ノードを更新する方法について説明します。

重要

更新操作を実行する前に、クラスタのバックアップ・ファイルを現在のバージョンで作成します。kubeadmパッケージを更新すると、作成するバックアップ・ファイルには下位互換性がなくなります。Kubernetesと使用するOracle Linux Container Servicesの以前のバージョンに戻す場合、リストア操作でバックアップ・ファイルが正常にロードできないことがあります。詳細は、第4.3項「クラスタのバックアップおよびリストア」を参照してください。

マスター・ノードを更新するステップ

  1. マスター・ノードで、最初にkubeadmパッケージを更新します。 

    # yum update kubeadm

  2. Oracle Container Registryを使用してイメージを取得する場合は、ログインします。

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

  3. 第2.2.7項「ファイアウォールとiptablesの要件」を参照して、新しいファイアウォール・ポートが開いていることを確認します。

  4. 更新前のバックアップ・ファイルを作成します。更新が正常に完了しない場合、バックアップは、更新前のクラスタの構成に戻すことができます。 

    # kubeadm-setup.sh stop
Stopping kubelet now ...
Stopping containers now ...

# kubeadm-setup.sh backup /backups
Creating backup at directory /backup ...
Using 3.2.24
Checking if container-registry.oracle.com/kubernetes/etcd:3.2.24 is available
d05a0ef2bea8cd05e1311fcb5391d8878a5437f8384887ae31694689bc6d57f5 
/var/run/kubeadm/backup/etcd-backup-1543581013.tar
9aa26d015a4d2cf7a73438b04b2fe2e61be71ee56e54c08fd7047555eb1e0e6f 
/var/run/kubeadm/backup/k8s-master-0-1543581013.tar
Backup is successfully stored at /backup/master-backup-v1.12.5-2-1543581013.tar ...
You can restart your cluster now by doing: 
# kubeadm-setup.sh restart

# kubeadm-setup.sh restart
Restarting containers now ...
Detected node is master ...
Checking if env is ready ...
Checking whether docker can pull busybox image ...
Checking access to container-registry.oracle.com/kubernetes ...
Trying to pull repository container-registry.oracle.com/kubernetes/pause ... 
3.1: Pulling from container-registry.oracle.com/kubernetes/pause
Digest: sha256:802ef89b9eb7e874a76e1cfd79ed990b63b0b84a05cfa09f0293379ac0261b49
Status: Image is up to date for container-registry.oracle.com/kubernetes/pause:3.1
Checking firewalld settings ...
Checking iptables default rule ...
Checking br_netfilter module ...
Checking sysctl variables ...
Restarting kubelet ...
Waiting for node to restart ...
.......+..............
Master node restarted. Complete synchronization between nodes may take a few minutes.

  5. マスター・ノードで、rootとしてkubeadm-setup.sh upgradeコマンドを実行します。スクリプトにより、更新を続行するよう求められ、続行する前にバックアップ・ファイルを作成するように警告されます。1と入力して続行します。 

    # kubeadm-setup.sh upgrade
Checking whether api-server is using image lower than 1.12
[WARNING] Please make sure that you have performed backup of the cluster before upgrading
          Please select 1 (continue) or 2 (abort) :
1) continue
2) abort
#? 1
Checking whether https works (export https_proxy if behind firewall)
v1.12.5-2: Pulling from kubernetes/kube-proxy-amd64
Digest: sha256:d3b87a1cb0eb64d702921169e442c6758a09c94ee91a0080e801ec41355077cd
Status: Image is up to date for 
       container-registry.oracle.com/kubernetes/kube-proxy-amd64:v1.12.5-2
Checking cluster health ...
 
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration options from a file: /var/run/kubeadm/kubeadm-cfg
[upgrade/version] You have chosen to change the cluster version to "v1.12.5-2"
[upgrade/versions] Cluster version: v1.12.7+1.1.2.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]
[upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.12.5-2"...
[upgrade/staticpods] Writing new Static Pod manifests to 
    "/etc/kubernetes/tmp/kubeadm-upgraded-manifests120255399"
[controlplane] Wrote Static Pod manifest for component kube-apiserver to 
    "/etc/kubernetes/tmp/kubeadm-upgraded-manifests120255399/kube-apiserver.yaml"
[controlplane] Wrote Static Pod manifest for component kube-controller-manager to 
    "/etc/kubernetes/tmp/kubeadm-upgraded-manifests120255399/kube-controller-manager.yaml"
[controlplane] Wrote Static Pod manifest for component kube-scheduler to 
    "/etc/kubernetes/tmp/kubeadm-upgraded-manifests120255399/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-manifests555128538/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[apiclient] Found 1 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-manifests555128538/kube-controller-manager.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[apiclient] Found 1 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-manifests555128538/kube-scheduler.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[apiclient] Found 1 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
[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: kube-dns
[addons] Applied essential addon: kube-proxy
 
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.12.5-2". Enjoy!
 
[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading 
    your kubelets in turn.
Warning: kubelet.service changed on disk. Run 'systemctl daemon-reload' to reload units.
 
[MASTER UPGRADE COMPLETED SUCCESSFULLY]
 Cluster may take a few minutes to get backup!
 Please proceed to upgrade your $WORKER node *in turn* by running the following command:
  # kubectl drain $WORKER --ignore-daemonsets (run following command with proper KUBECONFIG)
  Login to the $WORKER node
  # yum update kubeadm
  # kubeadm-setup.sh upgrade
  # kubectl uncordon $WORKER (run the following command with proper KUBECONFIG)
  upgrade the next $WORKER node

    upgradeコマンドにより、クラスタに対してヘルス・チェックを実行し、既存の構成を検証してから、クラスタの更新に必要なイメージをプルします。クラスタのすべてのcontrolplaneコンポーネントが更新され、すべてのノードのすべてのクラスタ・コンポーネントが更新後も機能し続けるように証明書とトークンが構成されます。

    これらのコンポーネントが更新されると、kubeletおよびkubectlパッケージが自動的に更新されます。

  6. 次のメッセージが表示された場合は、flannelコンポーネントを手動で更新する必要があることを示しています。 

    [INFO] Flannel is not upgraded yet. Run 'kubeadm-setup.sh upgrade --flannel' to upgrade flannel

    --flannelフラグを指定してkubeadm-setup.sh upgradeを再実行し、クラスタを完全にアップグレードしたことを確認します。 

    # kubeadm-setup.sh upgrade --flannel

マスター・ノードのアップグレードが完了したら、各ワーカー・ノードで、Kubernetesと使用するOracle Linux Container Servicesのパッケージをアップグレードできます。

2.6.2 ワーカー・ノードの更新

第2.6.1項「マスター・ノードの更新」の説明に従って、マスター・ノードの更新プロセスが完了した後にのみ、ワーカー・ノードを更新します。

重要

ワーカー・ノードの更新を完了するには、いくつかの手動ステップを実行する必要があります。これらのステップでは、更新前にノードをドレインし、クラスタで、更新中にノード上のポッドがスケジュールまたは開始されないようにします。ドレイン・プロセスにより、実行中のすべてのポッドがノードから削除されます。ローカル記憶域が構成されている場合は、ドレイン・プロセスでエラーが発生するため、それを受けてローカル・データをバックアップする必要があるかどうかを判断できます。

更新が完了したら、ポッドをこのノードで再開できるようにワーカー・ノードをuncordonできます。

ワーカー・ノードを更新するには、次のステップを実行します。

  1. マスター・ノードから次のコマンドを実行して、ワーカー・ノードをドレインします。 

    $ kubectl drain worker1.example.com --ignore-daemonsets

    ここで、worker1.example.comは、更新するワーカー・ノードのホスト名です。

    ノードにローカル記憶域が構成されている場合、ドレイン・プロセスでエラーが発生する可能性があります。次の出力例は、ローカル記憶域を使用していてドレインに失敗するノードを示しています。 

    node/worker1.example.com cordoned
error: unable to drain node "worker1.example.com", aborting command...
 
There are pending nodes to be drained:
 worker1.example.com
error: pods with local storage (use --delete-local-data to override): carts-74f4558cb8-c8p8x, 
    carts-db-7fcddfbc79-c5pkx, orders-787bf5b89f-nt9zj, orders-db-775655b675-rhlp7, 
    shipping-5bd69fb4cc-twvtf, user-db-5f9d89bbbb-7t85k

    ノードのドレインに失敗した場合は、ローカル・データをバックアップして後でリストアするなんらかの手順に従う必要があるかどうか、または続行してローカル・データを直接削除できるかどうかを決定します。バックアップ・ファイルが作成されたら、--delete-local-dataスイッチを指定してコマンドを再実行し、データを強制的に削除してノードをドレインできます。次に例を示します。 

    $ kubectl drain worker1.example.com --ignore-daemonsets --delete-local-data
node/worker1.example.com already cordoned
WARNING: Ignoring DaemonSet-managed pods: kube-flannel-ds-xrszk, kube-proxy-7g9px; 
Deleting pods with local storage: carts-74f4558cb8-g2fdw, orders-db-775655b675-gfggs, 
                                  user-db-5f9d89bbbb-k78sk
pod "user-db-5f9d89bbbb-k78sk" evicted
pod "rabbitmq-96d887875-lxm5f" evicted
pod "orders-db-775655b675-gfggs" evicted
pod "catalogue-676d4b9f7c-lvwfb" evicted
pod "payment-75f75b467f-skrbq" evicted
pod "carts-74f4558cb8-g2fdw" evicted
node "kubernetes-worker1" drained

  2. マスター・ノードで次のコマンドを実行し、ワーカー・ノードでこれ以上のスケジューリングを受け入れることができないことを確認します。 

    $ kubectl get nodes

    ドレインされたノードのステータスは、SchedulingDisabledに設定されている必要があります。

  3. 標準のyum updateコマンドを使用して、ワーカー・ノードでパッケージを更新します。Kubernetesと使用するOracle Linux Container Servicesに必要なこれらのパッケージのみを明示的に更新するには、ワーカー・ノードで、rootとして次のコマンドを実行します。 

    # yum update kubeadm

  4. Oracle Container Registryを使用してイメージを取得する場合は、ログインします。

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

  5. yum updateプロセスが完了したら、ワーカー・ノードで、rootとしてkubeadm-setup.sh upgradeコマンドを実行します。更新がノードの可用性に一時的に影響することが警告されます。更新を続行することを確認します。 

    #  kubeadm-setup.sh upgrade
[WARNING] Upgrade will affect this node's application(s) availability temporarily
          Please select 1 (continue) or 2 (abort) :
1) continue
2) abort
#? 1
Checking access to container-registry.oracle.com/kubernetes for update
v1.12.5-2: Pulling from kubernetes/kube-proxy-amd64
Digest: sha256:f525d06eebf7f21c55550b1da8cee4720e36b9ffee8976db357f49eddd04c6d0
Status: Image is up to date for 
container-registry.oracle.com/kubernetes/kube-proxy-amd64:v1.12.5-2
Restarting containers ...
[NODE UPGRADED SUCCESSFULLY]

    kubeletサービスおよび実行中のすべてのコンテナは、更新後に自動的に再起動されます。

  6. 必要に応じて、マスターノードで次のコマンドを実行し、新しいノードをスケジュールできるようにワーカー・ノードをuncordonします。 

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

    ここで、worker1.example.comは、更新したワーカー・ノードのホスト名です。

  7. 更新プロセスが完了したら、マスター・ノードで次のコマンドを実行して、すべてのノードで予期されるバージョンが実行されていることを確認します。 

    $ kubectl get nodes
NAME                  STATUS    ROLES   AGE       VERSION
master.example.com    Ready     master  1h        v1.12.7+1.1.2.el7
worker1.example.com   Ready     <none>  1h        v1.12.7+1.1.2.el7
worker2.example.com   Ready     <none>  1h        v1.12.7+1.1.2.el7

Copyright © 2012, 2020, Oracle and/or its affiliates. 法律上の注意点