Kubernetes を利用してシステムを設計するには、まだまだ、いろいろ資料として足りないのですが、これまで検証して書き溜めてきたことの中間的な整理とし書き残しておきたいと思い作成しました。少しずつでも更新していきたいと思います。

IBM Cloud Kubernetes 実装の特徴

従量制プランで Kubernetes (以下 k8s) のインスタンスを起動すると、IBM Cloud IaaS (旧SoftLayer) に k8s Worker node として、自身のユーザー管理下で仮想サーバーが起動します。一方、Master node は、IBM Cloudの管理として提供され、サーバーに直接ログインすることはできません。 Worker node は、ワークロードに対応して追加や削除ができます。

コマンドラインから IBM Cloud へログインした後は、kubectl コマンドを利用して k8s のクラスタを操作します。 Mater node の認証情報とEndpoint のアドレスが提供されるので、この情報を利用して kubectl コマンドで Master node をアクセスします。

k8sの構成概要

IBM Cloud のカタログから Kubernetes クラスタを作成すると Master node と Worker node が作成されます。

このIBM Cloud での k8s の実装概要図は次の様になります。図をシンプルにするため、ネットワーク・スイッチや冗長接続も省略しています。 Master node と Worker node の部分が k8sになっており、それ以外は旧SoftLayer の標準的な構成になっています。

この図の略称を以下に列挙しておきます。

IX: Internet Exchange の略で、ISP事業者やデータセンタ事業者などが相互接続して、経路情報やトラフィックを交換するための接続点です。
BB-Network: IBM Cloud の Back-Born Network を表しています。このネットワークは各地の PoP やデータセンタを相互に接続し、インターネットからDCへのトラフィックの通り道となります。
PoP: Point of Presenceの略で、バックボーン回線を収容するバックボーンルータを設置している場所のことです。
BBR: Back-Born Router の略で、IX, IBM Cloud BB そしてデータセンターを接続するルータで、PoPに配置されています。
DAR: Datacenter Access Router の略で、データセンターの入り口のルーターです。このルータには、ハードウェア・ロードバランサーが配置されるLANが接続されています。
MBR: Master Back-end Router の略で、DAR,BCR 及び共通サービスのネットワーク・セグメントを結びます。このセグメントには、永続ストレージ、VPN接続用VPNルータなど、ポータルから利用できる IaaS のサービスが配置してされています。
FCR: Front-end Customer Router の略で、各ユーザー専用のVLANのパブリック側の入り口となります。パブリックとはインターネットから到達できるIPアドレスを付与され、インターネットのグローバルから到達できることを意味しています。また、FCRにはハードウェア・ファイアウォールを配置するセグメントが接続されています。図の様に、ハードウェア・ファイアウォールの内側のインタフェースは、ユーザー専用に割り当てられるVLANへ接続されます。
BCR: Back-end Customer Router の略で、サーバーインスタンスが接続されるプライベートVLANの入り口になります。BCRはユーザー間で相互接続する目的では利用されません。

IaaS の Firewall や Load Balancer との関係

前述の構成から解る様に、k8sクラスタのインターネット側へ、ロードバランサとファイアウォールを配置することできます。この図は、ルータなど詳細な機器を省略して、ロードバランサとファイアウォールの配置に焦点をおき、検討するための図です。

次の図の左側では、IaaSとして利用できるロードバランサやファイアウォールを利用せず、k8sのロードバランサーや特定ポートの解放機能だけを利用して構成した例になります。特に理由がなければ、この図の左側の構成で、可用性を保ちつつ、サービスを提供することができます。
それに対して、右側のケースでは、k8s のクラスタ構成のフロントに、ロードバランサとファイアウォールを配置したケースケースです。このケースでは、ファイアウォールとロードバランサの費用が課金されますから、ちょっとコストのかかる贅沢な構成となります。インターネットに面するネットワークのセキュリティをより高くしたい、また、k8sのソフトウェアのロードバランサーでは、負荷に対応できるか懸念がある場合、専用のハードウェアのロードバランサで頑丈な構成にしたいなどの要求に対応するものです。もちろん、どちらか一方だけを利用することもできます。

IaaSの永続ストレージの利用

コンテナを利用する場合に、データを保存しておく場所が懸念事項になります。コンテナを入れ替えてもデータは維持する必要があります。そこで、k8sのyamlファイルに定義を追加することで、コンテナ自身に設定を加えず、Endurance Storage や Performance Storage などの永続ストレージをマウントする事ができます。

k8s とベアメタルサーバとの組み合わせ

k8s の Worker nodeはユーザー専用のVLANに配置されるため、同一の Private LAN 上に、ベアメタルサーバーや仮想サーバーのインスタンスをデプロイできます。特にベアメタルサーバーは、仮想化のためのハードウェアが無く、ダイレクトにハードウェアをアクセスしますから、CPUの能力100パーセントを、ユーザーの処理に当てる事ができます。このため、データベースなど特に高速なI/Oを要求するケースでは、性能面でとても有利になります。この構成では、コンテナの開発＆運用の効率化の特徴と無駄の無い高性能ベアメタルの良い部分を組み合わせて運用する事ができます。

また、ベアメタルには GP-GPUカードや PCIe接続型の Intel Optaine 高速SSD などのカードを利用できますから、性能を要求する様なケースに最適と言えると思います。

Cloud Foundry のサービスとの連携

IBM Cloud PaaS (旧Bluemix PaaS)のサービスと連携させる事ができます。 PaaSのサーバー群やサービス専用インスタンスにアクセスする場合は、必ずパブリック・ネットワーク経由での接続になりますから、Woker nodeとして仮想サーバーのアウトバンドの通信料金が課金されることを考えておく必要があります。共有サービスを利用するため、レスポンスが常に一定ではないことや、ネットワーク・アクセスの遅延が大きいケースがあることを念頭においておく必要があります。

k8sのコンテナから IBM Cloud PaaS のワトソンAPIのコールして、対話記録をCloudant に保存するなどの用途に活用する事ができます。

オンプレミスのシステムとの連携

旧SoftLayerで提供されている VPNサービスを利用して、Private VLAN に接続する事ができます。旧Bluemix PaaSの Secure Gateway は BluemixのプライベートVLAN上のサブネットに接続するためのサービスですから、k8sに提供できないことに注意する必要があります。

コンテナ監視

Weave Scope は、アプリのマップを自動的に生成し、コンテナ化されたアプリを直感的かつリアルタイムに把握、監視、および制御できるようにします。

ログ監視

IBM Cloud ログ監視は、Worker nodeで出力されるメッセージを全て ElasteicSearch保存する様に設定されています。特別にログのための仕組みを作る必要がなく、便利で生産性が高いと言えると思います。

IBM Cloud k8s検証メモ過去記事

あとがき

Grafana とか Istio も加えたいし、インフラの話ばかりだけど、もっとユースケースをベースにして書きたいですね。Woker nodeは時間課金の仮想サーバーなので、通信量が多い場合、月額課金に切り替えてプリペイド枠を追加したいのですが、どうしたら良いでしょうかね。まだ小慣れてない感じですが、頑張っていきたいと思います。

IBM Cloud Kubernetes 検証メモ 中間まとめ