企業ネットワーク最前線

<コンテナNWの課題と展望>Kubernetes環境のネットワークの基礎を学ぶ

文◎奈良昌紀、千葉豪(ネットワンシステムズ) 2019.12.11

  • bookmark
  • Teitter
  • 印刷

近年、大きな注目を集めている「コンテナ」と、そのオーケストレーションツール「Kubernetes」。ここでは、コンテナ環境におけるネットワークの課題や解決技術、そして今後の展望を説明する。

Dockerにおけるネットワークまず、広く使われているコンテナ化技術「Docker」を例として、コンテナネットワークの概要を説明する。コンテナは一般的にLinux OS上で起動する。このホストは「コンテナホスト」と呼ばれ、各コンテナはコンテナホスト内の論理的なネットワークに接続されている。

具体的には、コンテナホスト内に論理ブリッジ(Linuxブリッジ)が存在し、各コンテナは、LinuxのNetwork Namespace機能により隔離され、仮想ネットワークインターフェース(veth)でこのブリッジに接続される。これによって、コンテナ内のプロセスから見ると、自分専用のネットワークインターフェースがあるように見えている。

そして、コンテナホスト自身が持つネットワークインターフェースもこのブリッジに接続されているため、コンテナで起動するサービスを外部公開する場合には、コンテナホストに対するアクセスがLinuxカーネルのiptablesを使ってNATされる(図表1)。

 

図表1 Dockerのコンテナネットワーク
図表1 Dockerのコンテナネットワーク


Kubernetesでコンテナ群を管理さて、開発環境のように小規模なものであれば、1台のコンテナホスト内で必要なコンテナをすべて起動することができるため、上記のような実装で問題ない。

しかし、コンテナ数が多い場合や、本番環境のように可用性が求められる場合には、クラスター化が必要になる。ここで、分散したコンテナ群を効率的に管理するツールとして「Kubernetes」が登場した。

Kubernetesによるクラスター構成は次のようなものだ。「Master」と「Node」と呼ばれるLinuxホストで構成され、コンテナはNode上で「Pod」と呼ばれる単位で扱われる。このPodは、1つ以上のコンテナ、Podごとのファイルシステム、ネットワークインターフェースを持つ(図表2)。

 

図表2 KubernetesのNodeとPod
図表2 KubernetesのNodeとPod


【課題1】コンテナ間の通信このようなクラスター環境における課題は、コンテナ間の通信だ。Podには独立したIPアドレスが割り当てられるが、Node内でのみ有効なため、そのままではNodeを跨いだ通信は難しい。Dockerでは、LinuxのNAT機能を用いていたが、すべてのPod間通信をNATテーブルで制御するのは限界がある。そこで、多くのコンテナネットワークソリューションではVXLAN技術などによるオーバーレイネットワークが採用されている。

オーバーレイネットワークとは、パケットをカプセル化して送信し、受信側でカプセル化を解いて宛先に届けるものだ。具対的には、Podから送信されたパケットは、Node内のブリッジを経由してLinuxカーネルでカプセル化され、宛先Nodeに送信される。そして、受信したNodeはカプセル化を解いて宛先のPodにパケットを届ける(図表3)。

 

図表3 Podとオーバーレイネットワーク[画像をクリックで拡大]
図表3 Podとオーバーレイネットワーク

オープンソースでは「Flannel」(https://github.com/coreos/flannel)や、RedHat OpenShift Container Platformで利用されている「OpenShift SDN」(https://github.com/openshift/sdn)等がこのアプローチでコンテナ間の通信を実現している。OpenStackにおける仮想マシン間通信と同じ実装だ。

また、別の実装方法として、Podが持つIPアドレスをNodeネットワークに公開する方法もある。オープンソースの「Calico」(https://github.com/projectcalico/calico)は、Podに割り当てられるIPアドレスをBGPでNode外に広報し、各Nodeが経路情報を学習するものである。この手法であれば、基本的にNATは利用されず、パフォーマンスインパクトも小さい。また、BGPを利用することで、Nodeに接続しているネットワーク機器側でもPod向けネットワークが確認可能になる。
続きのページは「business network.jp」の会員の方のみに閲覧していただけます。ぜひ無料登録してご覧ください。また、すでに会員登録されている方はログインしてください。

スペシャルトピックスPR

Gigamon2009
netscout2009
microfocus2009

>> 今月の月刊テレコミュニケーション

月刊テレコミュニケーション【特集】5G
    これからどうなる?

●5GMF アプリ委員会委員長 岩浪剛太氏「5Gニーズは3年加速した」
●日本の5Gはこう進化する ●5G網でAPIエコノミー
●コンシューマー市場で劇的な展開はあるか ●米欧中韓は2020年内にSA開始
●SA化で火蓋切る企業活用 ●中国5Gは「地方」が熱い など

◆災害対策で進むIoT活用 ◆5G/IoT時代、地図はどうなる
◆ドコモ口座事件後のフィンテック ◆1円玉サイズのLeafonyが道開く ほか

>>詳しい目次を見る

スペシャルトピックス

日本シエナコミュニケーションズ光/IP融合で5G超低遅延

光伝送のリーダーであるシエナは、光/IP融合に磨きをかけ、5G URLLCとNWスライシングの効率運用に貢献

パイオリンク <帝京大学>ADCによる負荷分散で
オンライン授業の品質を担保

コロナ対策でオンライン授業に全面切替。パイオリンクのADC導入!

Cisco Webex Calling取り残されてきた「固定電話」
新しい働き方の鍵はクラウドPBX

テレワーク中の会社宛電話をどうするか? 解決策を探ってみよう!

マクセル太陽電池はもう時代遅れ!
リチウム電池で8年以上の持ち

マクセルの「IoT電源システム」は、リチウム電池を用いた従来ない電源

アイ・オー・データ機器リチウム電池で安定的に水位計測

アイ・オー・データの「水位監視用電池式IoT通信システム」ならコンパクトサイズで設置も簡単!

NECネッツエスアイ自然災害の被害をIoTで最小化

LPWAを活用した災害対策サービスを提供するNECネッツエスアイ。最適な通信規格がマルチに選べる!

スリーダブリューローカル5G局開設を全段階で支援
レンタルでコスト障壁に挑む

ローカル5G向けの基地局レンタルパッケージが提供開始!

マイクロフォーカスそのDevOps、個別最適になっていませんか?

全体最適を目指すならマイクロフォーカスの「Enterprise DevOps」

NVIDIA EGXエッジAIの最適解はGPUにあった!

NVIDIA EGXでエッジコンピューティングの課題を解決し、「スマートエブリシング革命」の実現を!

IDaaSクラウド時代の新常識! 今こそIDaaSを導入すべき3つの理由

クラウドを活用するなら、ID/アクセス管理もクラウドに!

ローデ・シュワルツローカル5Gの測定ニーズの
全てに応えるローデ・シュワルツ

設備構築時の干渉調査・エリア確認、運用開始後の管理までカバー!

MOVEit「パスワード付き圧縮ファイル」
にはもう頼らない!

多様なニーズに対応したファイル転送の姿とは?

Gigamonコロナ禍による通信量の増大に対応

モニタリング、セキュリティ装置の負荷軽減や運用効率化を実現するGigamon社の先進的なL1スイッチ!

ネットスカウトシステムズNWを堅牢にしながらDDoS対策も
ニューノーマルのセキュリティ対策

テレワークのセキュリティと可用性を同時に高める方法があった!

マイクロフォーカス通信キャリアの運用監視をDX

HPEのソフトウェア部門を統合したマイクロフォーカスに、通信キャリアの課題と解決策を聞いた。

tcs-8500遠隔診療がWeb会議でいいはずない!
ノイズなし4K映像伝送を低価格で

医療現場で求められる高画質・低遅延を1台で実現する「TCS-8500」

エンピレックス通信事業者にワンランク上の可視性を

5G時代、キャリアは運用の一層の効率化を迫られるが、クラウドネイティブならトータルコストも削減できる!

KDDIどうする? テレワーク移行時の意外な盲点「固定電話」の取り次ぎ

「固定電話の番のためだけに出社」から脱却するには、何が必要だろうか。

ホワイトペーパー

アクセスランキング

tc_banner191122

「通信」の力でビジネスを進化させるbusinessnetwork.jp

Copyright(c) 2020 RIC TELECOM Co.,Ltd. All Rights Reserved. 記事の無断転載を禁じます