• Cisco Container Platform インストーラ OVA

• 2 つの最新バージョンのテナント OVA

• 高可用性（HA）および分散リソース スケジューラ（DRS）が有効になっている vCenter クラスタ

• Cisco Container Platform インストーラ VM に IP アドレスを提供する DHCP サーバ

• クラスタ内のすべての ESXi ホストにマウントされている共有の仮想マシン ファイル システム（VMFS）データストア

• Cisco Container Platform コントロール プレーン VM では vCenter アプライアンス API へのネットワーク アクセス権が必要

• Cisco Container Platform 1.3.0 以降では、Ivy Bridge 以降の新しいマイクロアーキテクチャの CPU を実行するハイパーバイザ ホストが必要です。

• Kubectl バージョン 1.11 以降

• Kubernetes 1.12 テナント クラスタのサポート

  • ACI 3.2(4e) をサポートしています。

    注：このバージョンの ACI CNI は Kubernetes 1.12 をサポートしています。

• コントローラとテナント クラスタのノード IP アドレスが Cisco Container Platform によって自動的に割り当てられる

• Kubernetes 1.10 のサポートを削除

• 展開または SSH アクセスで Ed25519 または ECDSA デジタル署名アルゴリズムの使用をサポート

• 安全性が低い RSA と DSA デジタル署名アルゴリズムのサポートを削除

• VM への SSH アクセス用のパスワード認証が許可されない

• パスフレーズの変更にユーザのパスフレーズが必要

• ACI の展開で Cisco Container Platform のクラスタ名が ACI テナント名と同じに

  たとえば、Cisco Container Platform のテナント名が ccp-tenant-1 の場合、ACI テナント名は ccp_tenant_1 です。

• Cisco Container Platform のインストールおよびアップグレード時に LDAP/AD の設定をサポート

• OVF プロパティを使用したインストーラ VM の NTP サーバの設定をサポート

Cisco Container Platform の具体的な設置手順については、『Cisco Container Platform Installation Guide』を参照してください。

• Cisco Container Platform のアップグレードは、CNI に Calico または ACI を使用した展開について、リリース 1.5.0 からサポートされています。

• 既存の展開で CNI に Contiv を使用している場合、現在のバージョンへのアップグレードはサポートされていません。

• EKS クラスタの AMI オプションのリストを修正

• Cisco Container Platform Web インターフェイスのバグを修正

• Cisco Container Platform のバージョンが 2.2.2 よりも前の場合に、クラスタ名に大文字が含まれているとアップグレードが失敗します。

  回避策

  1. Cisco Container Platform コントロール プレーンのマスター VM に SSH 接続し、「ccp-appdata」テーブルでクラスタ名を小文字に変更します。

     sudo apt-get update
      sudo apt-get install -y jq
      kubectl exec -it mysql-0 -- mysql -p$(kubectl get secret mysql -o json | jq -r '.data["mysql-root-password"]' | base64 -d) ccp-appdata -e "update keyvalues_keyvalue set value = replace(value, 'CCP-CLUSTER-NAME', lower('CCP-CLUSTER-NAME')) where instr(value, 'CCP-CLUSTER-NAME') > 0;"
      kubectl exec -it mysql-0 -- mysql -p$(kubectl get secret mysql -o json | jq -r '.data["mysql-root-password"]' | base64 -d) ccp-appdata -e "select * from keyvalues_keyvalue;"

  2. VSphere のローカライズ版を使用している場合は、次の手順に従って、クラスタ データ用のデータストア フォルダの名前を変更します。

     1. vSphere Web Client で、[vCenter] をクリックします。

     2. [Storage] タブをクリックします。

     3. 左側のペインから、クラスタの作成に使用するデータストアを選択します。

     4. クラスタ名を変更するフォルダを選択します。

        例：CCP-CLUSTER-NAME

     5. フォルダの名前を同じ名前の小文字に変更します。

        例：ccp-cluster-name

  3. 次の手順に従って、既存のディスク パスで小文字名が使用されるようにします。

     1. [Virtual Machines] タブをクリックし、ccp-cluster-name-masterxxxxx という名前の VM を選択し、[Edit settings] をクリックします。

     2. [Harddisk 2] を削除します。

     3. [Manage Other Disks] タブをクリックし、[Harddisk] を削除します。

     4. [Add Existing Hard Disk] をクリックし、datastore/<使用しているクラスタ名>/etcd.disk からディスクを選択します。

     5. [Add Existing Hard Disk] をクリックし、datastore/<使用しているクラスタ名>/cert.disk からディスクを選択します。

  4. 同じクラスタ名を小文字で使用して、Cisco Container Platform のアップグレードを開始します。

• HyperFlex 3.5.2 へのアップグレードで、ボリューム トラフィックの中断が発生します。

  注：ここでの説明は、Kubernetes の HyperFlex Flex ボリューム プラグインを使用している場合にのみ適用されます。

  HyperFlex 3.5.1 またはそれ以前では、ESXi ホスト上の vSwitch で使用されている IP アドレスは 169.254.1.1 でした。HyperFlex クラスタのうち Storage Hypervisor Network のアドレスの範囲が 169.254.1.0/24 のものは、169.254.1.1 と競合していました。この IP 競合の問題を回避するため、HyperFlex 3.5.2 ではデフォルトの IP アドレスが 169.254.254.1 に変更されています。この変更により、Kubernetes ノードの Flex ボリュームの設定はアップグレード後に正しくなくなります。

  回避策

  注：この問題を回避する場合、次に示す 2 つのオプションのうちいずれか 1 つだけを使用してください。

  オプション 1：HyperFlex コントローラの VM の設定を変更する

  ESXi で 169.154.1.0/24 の範囲を使用している既存の HyperFlex クラスタが存在しない場合は、このオプションを選択できます。このオプションでは、これらのクラスタで Kubernetes ノードの設定を変更する必要がなくなります。

  HyperFlex を 3.5.2 にアップグレードした後、次の手順に従ってデフォルトの IP アドレスを 169.254.1.1 に変更します。

  1. 次のコマンドを実行し、application.conf ファイルで iscsiTargetAddress = "169.254.254.1" を探し、iscsiTargetAddress = "169.254.1.1" に置き換えます。

       sed -i -e 's/iscsiTargetAddress*169.254.1.1/iscsiTargetAddress*169.254.254.1/g' /opt/springpath/storfs-mgmt/hxSvcMgr-1.0/conf/application.conf 

  2. 次のコマンドを実行し、application.conf ファイルで istgtConfTargetAddress = "169.254.254.1" を探し、istgtConfTargetAddress = "169.254.1.1" に置き換えます。

      sed -i -e 's/istgtConfTargetAddress*169.254.254.1/istgtConfTargetAddress*169.254.1.1/g' /opt/springpath/storfs-mgmt/hxSvcMgr-1.0/conf/application.conf

  3. 次のコマンドを実行し、下記のサービスを再起動します。

      restart hxSvcMgr
      restart stMgr

  オプション 2：すべての Kubernetes VM の設定を変更する

  ESXi で 169.154.1.0/24 の範囲を使用している既存の HyperFlex クラスタが存在する場合は、このオプションを選択できます。Kubernetes クラスタの操作（スケールアップやアップグレードなど）の後に、新しい VM でこのステップを繰り返す必要があります。この理由から、望ましい解決策としてはオプション 1 の方をお勧めします。

  HyperFlex を 3.5.2 にアップグレードした後、すべての Kubernetes VM について次のコマンドを実行し、hxflexvolume.json ファイルで "targetIp": "169.254.1.1" を探し、"targetIp": "169.254.254.1" に置き換えます。

  ssh -l <ssh user> -i <private key file> <VM IP> -- sed -i -e 's/169.254.1.1/169.254.254.1/g' /etc/kubernetes/hxflexvolume.json

  （注）

  <ssh user> は、クラスタの作成時に指定したユーザと一致する必要があります。

  <private key file> は、クラスタの作成時に指定した公開キーに対応している必要があります。

• Cisco Container Platform Web インターフェイスの [Cluster Details] 画面にある [Upgrade] ボタンが現在動作していません。

  回避策

  [Clusters] 画面からテナント クラスタをアップグレードすることができます。

• コントロール プレーンのアップグレード中に、[Verify Network] 画面で [SUBNET CIDR] フィールドを変更すると、[IP ADDRESS RANGE] が更新されます。

  回避策

  注：この問題を回避する場合、次に示す 2 つのオプションのうちいずれか 1 つだけを使用してください。

  オプション 1：

  [Authenticate CCP] 画面に移動し、必要なデータを入力して、[NEXT] をクリックします。

  元の IP アドレス範囲が復元されます。

  オプション 2：

  Contiv または Calico の展開で、[Network Editing] 画面から元の IP アドレス範囲を見つけます。

  （注）

  • 2.2.x よりも前の ACI の展開では、元の開始および終了 IP アドレスは既存のコントロール プレーンの IP アドレスです。

  • 2.2.x 以降の ACI の展開では、元の開始および終了 IP アドレスは、Cisco Container Platform のインストール時に設定されたものと同じです。

• ACI と Kubernetes 1.12 を一緒に展開する場合、展開時に Cisco Container Platform によって NGINX コントローラと Fluentd ポッドが設定されます。展開後にポッドが再起動すると、ポッドの設定が失われます。

  回避策

  次のコマンドを実行して再度ポッドを設定します。

  kubectl annotate pod <POD NAME> -n ccp opflex.cisco.com/computed-endpoint-group='{"policy-space":"<ACI TENANT NAME>","name":"kubernetes|kube-default"}' --overwrite=True

• ACI テナントのアップグレード時は、[Subnet] フィールドを無視しても問題ありません。

• Cisco Container Platform では、このリリースに関連付けられている Kubernetes 1.11 または 1.12 のイメージを使用する必要があります。古いバージョンのテナント ベース イメージはサポートされていません。

• ACI テナント クラスタは Kubernetes 1.11.3 によるリンクローカル インターフェイスでは機能しません。

• 使用できるテナント イメージは、現在のリリースに関連付けられている最新の 2 つのバージョンのみです。古いバージョンのテナント ベース イメージの使用はサポートされていません。

• テナント クラスタをスケールアップするとき、または、古いバージョンの Cisco Container Platform を使用して作成したクラスタに新しいノード プールを追加するときに、エラーが発生します。

  回避策

  テナント クラスタをスケールアップしようとする前、または新しいノード プールを追加しようとする前に、Cisco Container Platform をアップグレードする必要があります。

• Kubernetes 1.11.3 API サーバには、既知のメモリ リークの問題があります。

• HyperFlex をダイナミック プロビジョナーとして使用している場合、ボリュームのマウントが次のエラー メッセージで失敗することがあります。

  MountVolume.SetUp failed for volume "xxxxx" : mount command failed, status: Failed to mount volume xxxxx, reason:

  回避策

  1. 次のコマンドを使用して esx サーバで scvmclient を再起動します。

     /etc/init.d/scvmclient restart

  2. ステータスが実行中であることを確認します。

• テナント クラスタにおける CNI としての Contiv は Tech Preview としてのみサポートされており、新しいバージョンの Cisco Container Platform へのアップグレードはサポートされていません。

• ACI 環境では、Cisco Container Platform ダッシュ ボードからテナント クラスタの Kubernetes ダッシュボードへのリンクはサポートされていません。Kubernetes ダッシュボードにテナント クラスタを表示するには、 kubectl get svc を使用して外部 IP アドレスの [Ingress IP] を取得する必要があります。

• Cisco Container Platform の Web インターフェイスには、スマート ライセンスなどの外部ページへのリンクが表示されます。ページへのアクセス権がない場合、それらのページを起動することはできません。

• クラスタの作成に失敗した場合、仮想 IP アドレスが解放されません。

• Contiv の展開では、NetworkPolicy に matchExpressions を使用しないでください。

• Contiv の展開では、ネットワーク ポリシーで hostnetwork ポッドが機能しません。

• Contiv の展開では、ポッドの CIDR は少なくとも /14 ネットワークである必要があります。

• Calico の展開での現象：

  • ラベルに一致するネットワーク ポリシーでは、ポッドまたはサービスへの hostnetwork アクセスがブロックされません。

  • ホスト IP の変更はポッドのネットワーキングに影響を与える可能性があります。問題を解決するには、Calico ポッドを再起動する必要があります。

• Istio を有効にすると istioctl がインストールされません。

  回避策

  次のコマンドを実行して istioctl を展開します。

  export ISTIO_VERSION=1.0 
  curl -L https://git.io/getLatestIstio | sh - 
  chmod +x istio-${ISTIO_VERSION}/bin/istioctl 
  sudo mv istio-${ISTIO_VERSION}/bin/istioctl /usr/local/bin/ 
  istioctl version  
  

  詳細については、『Cisco Container Platform User Guide』の「Monitoring Istio Service Meshes」の項を参照してください。

• Istio をバージョン 0.8 からバージョン 1.0 にアップグレードする場合、バックエンド サービスの応答が停止し、手動で再起動する必要があります。

• テナント クラスタをアップグレードする場合、新しいバージョンをインストールする前に Prometheus コンポーネントと EFK コンポーネントが削除されます。履歴を保存する場合は、テナント クラスタをアップグレードする前に、手動でバックアップと移行を行う必要があります。

• Cisco Container Platform によって管理されている VM のスナップショットの作成は、現時点ではサポートされておらず、アップグレード中は失敗します。

• ACI の展開はオンライン モードでのみサポートされます。

• ACI の展開では Kubernetes のセキュリティ コンテキストはサポートされていません。

• テナント クラスタに cert-manager が展開されるようになりました。これは Tech Preview としてサポートされています。