Hatでコンサルタントをしている織です。こちらの記事では、upstreamのKubernetesとMultusを使ってKVM環境上でMultusを検証しました。v4.3を使ってMultusを動かしてみます。v4では、環境構築の方法が大きく2種類あり、IPIはそのうちのひとつです。ネットワーク、ロードバランサ、DNSレコード、仮想マシンインスタンス等、OpenShiftのインストールに必要なインフラのコンポーネントをインストーラが自動的に作成します。workerノードのオートスケールができるようになったりします。インフラをAPIで制御できる環境(例えばIaaS)上にOpenShiftクラスターを構築するときはこちらが便利です。ネットワーク、ロードバランサ、DNSレコード、仮想マシンインスタンス等、OpenShiftのインストールに必要なインフラのコンポーネントは、あらかじめユーザーが自身で用意しておく必要があります。インストーラはその上にOpenShiftをインストールします。CoreOSではなく)RHELを使いたい場合等はUPIを使います。作成されるEC2インスタンスはNIC(ENI)を1個しか持たないノードは異なるAZにまたがって分散配置という構成になります。AWS上のOpenShiftでMultusを使う場合は、おそらくUPIで環境を作ることになるかと思うのですが、今回はIPIインストールで構築した環境に対して、少しカスタマイズしてMultusを使えるようにしました。深い理由はありません。実際に行ったカスタマイズは以下です。v4では、クラスターに対する設定は全てOperator経由で行う作りになっています。Operator(CNO)が司ります。createしましたが、OpenShiftではCNO経由でNetworkAttachmentDefinitionを作るよう、CNOに対して指示します。この辺りが本記事で一番言いたかったことなのですが、いろいろ余計なことを書いたので長くなってしまいました。v4.3.0[1]の環境を構築します。CoreOS)を使ったEC2インスタンスを起動してOpenShiftクラスターを構成する、という一連の作業をコマンド一撃でやってくれます。clusterAWS上でIPI方式でOpenShiftをインストールする手順の詳細は下記をご参照ください。公式のインストール手順[2]猿でもできるOpenShift4インストール編また、本検証ではやりませんでしたが、もしUPIを使ってインストールする場合は下記をご参照ください。UPIでのベアメタル環境へのインストール手順[3]OpenShiftを爆速でインストールしたいあなたへMultusのために環境をカスタマイズIPIインストールでAWSにOpenShiftクラスターを構築すると、下図のような構成になります(EC2インスタンスとVPCのプライベートネットワークのみ記載しています)。IPIインストールでAWSにできるOpenShiftクラスターMultusでもうひとつNICを使うので、これをカスタマイズして、最終的に下図のようにしたいです。各AZにサブネットを追加し追加サブネットごとに接続するENIを作成し作成したENIを各workerノードにアタッチするというカスタマイズをします。サブネットの追加Multusで追加接続するためのサブネットを各リージョンに作成します。IPv4のアドレスブロックは、VPCのアドレスブロックから適当に切り出します。10.0.203.0/24を作成しました。Key=Name,Value=${multus_subnet_name}みたいな感じです。各リージョンのworkerノードを追加したサブネットに接続するため、追加サブネットごとにENIを作成します。今回は下記のIPアドレスを使うことにします。10.0.203.29ipvlanでPodに付与するIPアドレスを、あらかじめENIのセカンダリプライベートIPv4アドレスとして列挙しておきます。Key=Name,Value=eni-${multus_subnet_name}ENIをworkerノードへアタッチ作成したENIを、各workerノードにアタッチします。${interface_id}workerノードの確認ENIをworkerノードにアタッチすると、workerノードのRHCOS(カーネル、ユーザーランドのコードはRHEL8と全く同じ[4])のカーネルが動的に追加インターフェースをens4として認識してくれます。workerノードでそのことを確認してみます。v4.xでmaster/workerノードに入ってOSコマンドを実行する方法は2つあります。インストーラ(openshift-installerコマンド)実行ノードのssh-agentに鍵が登録されていれば、それをRHCOSのユーザーcoreのauthorized_keysに登録してくれます。node/NODENAMEを実行します。node/ip-10-0-133-117.ap-northeast-1.compute.internalどちらの方法で確認しても構いませんが、1.を実施するには、IPIインストールで作成したVPCサブネット上に外部からアクセスするための踏み台サーバが必要になります。どちらかの方法でworkerノードに入って、インスタンスのインターフェースを確認します。foreverens3が元々インスタンスが持っていたENIで、ens4が先ほど追加したENIです。ルーティングテーブルを見てみます。tun0ens4にもDHCPからもらったデフォルトゲートウェイが設定されていて気持ち悪いので、ens4ではDHCPでIPアドレスだけをつける(DHCPによるデフォルトゲートウェイとDNS設定をしない)ようにします。2に対して、ipv4.ignore-auto-dnsとipv4.ignore-auto-routesを有効化します。/org/freedesktop/NetworkManager/ActiveConnection/3)これで、余分なデフォルトゲートウェイの設定が消えました。tun0各workerノードに対してこの操作を実施しておきます。Multusのセットアップ次にMultusの設定を行います。基本的にこちらの手順に従います。Resourceを作成しました。Operator)[5]が司る仕組みになっています。したがいまして、CNOに対してNetworkAttachmentDefinitionを作成してもらうよう指示する必要があります。Resourceで設定する内容を記載します。}'のような内容を記載しました[6]。この内容は、ap-northeast-1aリージョン(追加サブネットのIPv4アドレスブロックが10.0.201.0/24)のworkerノードにPodをデプロイしたい場合の設定です。routeの設定は、デプロイ先のworkerノードがいるリージョンごとに変える必要がありますのでご注意ください。}]'のように反映させることもできます。net-attach-defを実行し、作成したNetworkAttachmentDefinitionの内容を確認します。}]}}'Podのデプロイ1つ目のPodのデプロイ本検証では、下記のような設定のPodをデプロイします。routeを設定するまず、ap-northeast-1aのAZにいるworkerノードにデプロイすることを考えます。準備として、各ノードがどのAZにいるかを確認します。@text'["ip-10-0-158-197.ap-northeast-1.compute.internal","ocp43-9ld5l-worker-ap-northeast-1c-cphxt"]["ip-10-0-149-79.ap-northeast-1.compute.internal","ocp43-9ld5l-master-1"]["ip-10-0-143-118.ap-northeast-1.compute.internal","ocp43-9ld5l-master-0"]["ip-10-0-133-117.ap-northeast-1.compute.internal","ocp43-9ld5l-worker-ap-northeast-1a-vcnxn"]["ip-10-0-167-226.ap-northeast-1.compute.internal","ocp43-9ld5l-master-2"]["ip-10-0-162-156.ap-northeast-1.compute.internal","ocp43-9ld5l-worker-ap-northeast-1d-x62nl"]["ip-10-0-46-214.ap-northeast-1.compute.internal","bastion-ocp43"]ap-northeast-1aにいるworkerノードはip-10-0-133-117.ap-northeast-1.compute.internalであることがわかりました。次にそのノードのラベルを確認します。beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=m4.large,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=ap-northeast-1,failure-domain.beta.kubernetes.io/zone=ap-northeast-1a,kubernetes.io/arch=amd64,kubernetes.io/hostname=ip-10-0-133-117,kubernetes.io/os=linux,node-role.kubernetes.io/worker=,node.openshift.io/os_id=rhcosノードのセレクタとして、ラベルkubernetes.io/hostname=ip-10-0-133-117を使うことにします。このラベルをnodeSelectorで指定し、ipvlanの追加インターフェースに対して10.0.201.27/24を付与するPodipvlsan-1のmanifestは次のようになります。ip-10-0-133-117このファイルをipvlan-ocp-27-1.yamlに保存して、下記コマンドでPodをデプロイします。ipvlan-ocp-27-1.yamlPodが起動したら、期待する設定が反映されているか確認します。foreverMultusによるipvlanの追加インターフェースがnet1として、指定したIPアドレスが付与した状態で存在することが確認できました。次にPodのルーティングテーブルを確認します。routeが設定されています。routeにより、ipvlanの追加インターフェースを使った通信をリージョン(workerノード)をまたいで行うことができるようになります。2つ目のPodのデプロイ次は、ap-northeast-1cのAZにいるworkerノードにPodをデプロイします。routeが必要になります。route設定の内容を次のように変更します。patchで変更を実施します。}]}}"}]}}'network-ipvlanが期待する内容に変わったことが確認できたら、次のようなmanifestでPodを起動します。ip-10-0-158-197nodeSelectorとしてデプロイ先のAZにいるworkerノードについたラベルを指定し、annotationでPodのIPアドレスを指定しています。Podのデプロイができたら、Podに入ってIPアドレスを確認します。foreverルーティングテーブルも確認します。route設定が無事反映されていることが確認できました。Podipvlan-1と疎通できることも確認しておきます。実際に追加サブネットを通って通信できているかを、ホスト上でtcpdumpして確認したくなるかもしれません。コンテナホストのRHCOSはコンテナ実行に特化しているため、tcpdump等のツールは入っていないのですが、support-toolsというコンテナを使うとtcpdumpできるようになります。1つ目のPodをデプロイしたノードに入ります。/hostsh-4.4#次にtoolboxというコマンドを実行します[7]。このコマンドを実行すると、support-toolsコンテナを取得し、privilegedかつホストネットワークを掴んだ状態でデプロイし、その中に入ります。これで、ホストのインターフェースに対してtcpdumpが使えるようになります[8]。/]#裏でipvlan-2からipvlan-1に対してpingを打ち続けながら、このsupport-toolsコンテナの中でens4に対してtcpdumpを実行してみます。request/replyのやり取りをしていることが確認できました。Podのログを確認してください。CNOのPod名を確認します。podの出力を確認してください。それで当たりがつかない場合は、デプロイ先のworkerノードのログを確認します。crioサービスのログにエラーメッセージが出ていないかを最初に見るのがよいと思います。nodeでログインし、journalctlで確認します[9]。-f最後にIPIインストールで構築したOpenShiftクラスタに対してサブネットとNICを追加し、Multusを使って2つのネットワークに接続するPodをデプロイし、追加サブネット経由でPod間通信ができることを確認しました。Resourceを作り直しました。これはとても煩雑で、できればやりたくありません。対応策はいくつか考えられます。routeを設定しても、同じようにパケットを流すことができます。route設定が反映されます)。route設定を変更する必要がなくなります。routeの設定を切り替えたい場合はこちらの方法が使えるとうれしそうです。v4.3ではまだ使えません。今後のMultusの進化に期待しましょう。HatでNFVPEをしている林さんにいろいろ教えていただきました。日本語版はこちらにあります。GA直後なのに日本語のドキュメントがあるなんて素敵ですね。CoreOS)のOSイメージは、RHEL8と同じrpmパッケージを使いつつ(つまり入っているバイナリはRHEL8と同じ)、rpm-ostreeを使ってOSイメージを作成しています。Atomic由来のツールで、ユーザーデータ(/etcや/var)への影響なしにOSイメージをアトミックにロールバックできる仕組みを提供します。Linuxで使っていたIgnition等の仕組みを悪魔合体させたディストリビューションと言えます。RHCOS自体は(今のところ)、OCP(OpenShiftの製品版)のノードを動かすOSとしての使い方しかサポートされません(つまり汎用OSとして使うユースケースはサポートされません)。CoreOSは、コンテナホストに特化した汎用OSとして使われることを想定して開発が進められています。Operatorについては、こちらもご参照ください。v4.3のMultusだとこの書き方がCNOにはじかれてしまうので、少し古い書き方をしています。みたいな感じのことをやっています。Hat製品で問題判別時の情報収集に使うsosreportコマンドも、support-toolsコンテナ経由で実行できるようになります。実行しておくと、journalctlコマンドのページャが横スクロールせずにターミナルの右端で折り返してくれるので、ちょっとだけ幸せになれます。対応策2を実現する実装として、cni-route-overrideが提案されています。routeの設定を、cni-argsから差し込みます。Hatでコンサルタントをしている織です。Hatでコンサルタントをしている織です。HatでOpenShiftのサポートをしているid:nekopです。各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。