Blog

Kubernetes でリクエストを Pod に負荷分散する際にクライアントの送信元 IP アドレスを保持したいケースがあります。LoadBalancer や NodePort を使用する Service の場合、負荷分散の過程で送信元 IP アドレスが NAT（SNAT：Source NAT）されるため、Pod に到達するパケットからはクライアントの IP アドレスを知ることができません。Service の External Traffic Policy を Local に設定すると、外部からのトラフィックは受信したノード上の Pod にのみ転送されるため SNAT は回避できますが、単一ノードにトラフィックが集中するためクラスタワイドな負荷分散ができません。また、Ingress Controller を利用すると HTTP X-Forwarded-For ヘッダに送信元情報を付加することができますが、L7 LB が前提となるため、L4 LB のような低レベルロードバランサでは有効に機能しません。ベアメタル Kubernetes でネットワークロードバランサをプロビジョニングするための代表的な OSS に MetalLB があります。MetalLB には L2 モードと BGP モードの 2 種類の負荷分散方式が用意されています。多くの場合は前者が利用されますが、後者の BGP モードでは、より柔軟なネットワーク構成や負荷分散の制御が可能になり、送信元 IP アドレスを保持したままリクエストを分散することができます。今回のブログでは、MetalLB の BGP モードを利用して SNAT を回避しつつ、クラスタワイドな負荷分散を実現する構成について紹介したいと思います。

Hi there, Happy New Year! 🐉 I'm about to embark on a journey that's both for an IEEE international-conference and my graduation trip. My destinations: Hawaii (Oahu) and Las Vegas, USA. The International-Conference on Consumer Electronics (ICCE) and Consumer Communications & Networking Conference (CCNC) are academic conferences hosted by Institute of Electrical and Electronics Engineers (IEEE). These events focus on discussing the latest research and technological advancements in consumer electronics and communication technologies. Last year, my demonstration paper was accepted at CCNC 2024. I will be presenting the concept of the CYPHONIC adapter demonstration, which I've been researching and developing. A few of my colleagues will also be presenting at the conference. After the international-conference, I plan to visit CES 2024 as well. I'll be updating this blog daily as a travel diary. Alright-off I go! ✈️

サーバ仮想化技術は、物理サーバのコンピュートリソースを最大限活用するために、従来から利用されてきました。 サーバ仮想化を実現する代表的なハイパバイザに KVM（Kernel-based Virtual Machine） があります。 KVM は、オープンソースでありながら高い性能と安定性を持ち、Linux に深く統合されていることから、多くのオンプレミス環境やプライベートクラウドで採用されてきた実績があります。昨今ではパブリッククラウドが普及したことで、オンプレミスのサーバから GCE や EC2、AVM といったコンピュートマシンへのリフトアンドシフトが進んでいます。 大半の場合、パブリッククラウドが提供するコンピュートマシンは、それ自体が仮想化された VM として提供されます。ここで、従来利用してきた「KVM によるサーバ仮想化はクラウドプロバイダが提供する VM でも利用できるのか」という疑問が生じました。答え、クラウドプロバイダが提供する VM でも Nested Virtualization（Nested V12n） という仕組みを利用できます。 Nested V12n は、その名の通りネストされた仮想化を意味し、VM の中で別の VM を実行（VM in VM）することを指します。 Nested V12n を使用すると、クラウドプロバイダが提供する VM 内で KVM を利用することができます。しかし、実際にはオンプレミスの物理マシンとクラウドプロバイダが提供する仮想マシンでは、KVM の構築に際して仕組み上異なる部分があり、後者の場合は特有の制約もあります。今回のブログでは、Google Cloud の VM（GCE）で Nested V12n を利用し、libvirt を用いて Linux KVM を構築してみたので、クラウドサービスの VM で KVM を実行する方法や、VM ネットワークの違いについて紹介したいと思います。

株式会社 AbemaTV Cloud Platform Team にて ABEMA を構成するマイクロサービスのデプロイ状況を可視化するモニタリングツールの開発・導入ミッションに臨みました。本記事は 「CyberAgent Developers Blog - ABEMA におけるマイクロサービスデプロイ状況可視化のための内製モニタリングツールの開発」 に掲載された内容です。

クラウドサービスや Third-party ベンダが普及する昨今、各サービスを連携する上で、OIDC や OAuth 2.0 という言葉をよく耳にすると思います。これらの仕組みは、サービスを利用する際のセキュリティを担保する上で重要となる、認証・認可を提供するための基本的な規約（プロトコル）になります。OAuth 2.0 や、その仕組みを流用して拡張された OIDC は複雑で、認証・認可において多くのフローを辿ります。毎回、再調査をするのが大変なので、認証・認可の仕組みについて一度整理しておきたいと思います。