精鋭エンジニアがリレー解説 Kubernetes / NGINXの注目ユースケースと設定方法第3回

オンプレミス環境のKubernetesに潜む、セキュリティ×利便性のジレンマを解決する

2021年9月29日 14:33

はじめに

本連載では、NGINX(エンジンエックス)が求められている時代背景と、そのユースケース、具体的な設定手順について複数回に分けて解説致します。第3回目となる本稿では、オンプレミスでも導入ニーズが根強いKubernetes環境において、F5 IngressLinkを使ったADC管理者とアプリ開発者の棲み分けなどセキュリティと利便性を両立する具体策を解説します。

オンプレミスのKubernetes、
ADC管理者とアプリ開発者の棲み分けは?

クラウドネイティブの技術であると呼称されることも多いKubernetes(以下、k8s)ですが、オンプレミスでの導入要望が少なからずあるのも事実です。

Kubernetes Environments
https://www.cncf.io/wp-content/uploads/2020/11/CNCF_Survey_Report_2020.pdf

その理由の多くはデータ機密性保持、厳格なセキュリティポリシーによるもので、もちろんクラウドによる柔軟なスケーリング、冗長性などの利点を享受できません。

しかし、コンテナの抽象化技術によりオンプレミスでもまさに“クラウドのような”機能も含めたアプリケーション基盤を構築することも可能であり、セキュリティ×利便性のジレンマ解決に一石を投じていると言えます。

K8s環境でサービスを公開する場合、基本的には外部ADC(ロードバランサ機能)を利用します。クラウドであればLoadbalancer Serviceとして公開することで、クラウド側で外部からのアクセスを受けるためのロードバランサが自動で作成されます。オンプレミスにおいてもF5 Container Ingress Services(F5 CIS)などLoadbalancer Serviceに対応したソリューションを用いることで同等のサービス公開が可能です。

ただしクラウドと異なり、その外部ADCには管理者が存在し、ひいては設計・設定ポリシーが存在します。開発者は開発者で、それぞれのアプリケーションごとに許可したいトラフィック、迅速なテスト環境構築などの要望を持っています。時には相反することもあるこれらのポリシーと要望、どう実現するのが望ましいのでしょうか?

F5 IngressLinkで作業範囲を明確化

1つの解としてそれぞれの担当範囲を明確にする、というものが挙げられます。「それはそっちの仕事では?」「こちらの仕事ではない」…ビジネスのゴールは双方で共有しているものの、その見る視点が変われば意見も異なるということは想像に難くないでしょう。

この曖昧な作業範囲の議論に時間を費やしてしまい、アプリケーションのリリースが遅れ、結果としてビジネスチャンスを逸してしまう可能性が…と、ここでF5にお時間を下さい。

この図ように、F5 IngressLinkにより作業分界点を明確にすることで、上述の課題解決を図ります。さらに、より迅速かつ安全にアプリケーションをユーザに届けるべく以下の機能を提供します。

IngressLinkの機能をご体験頂くため、ベーシックな環境での設定手順をご案内します。

IngressLink検証環境構築

本記事では初期セットアップ済み時点からのご案内となりますが、以下参考情報となります。

BIG-IP LTM 簡単セットアップガイド(v14.1 対応)
https://www.f5.com/content/dam/f5/corp/global/pdf/jp/LTM_easy_Setup_v14.1_20191015_j%20.pdf

kubeadmを使用したクラスターの作成
https://kubernetes.io/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/

大枠は以下の通りです。

具体的な手順は別途資料をご参照下さい。

おわりに

今回はアプリケーションデリバリーにおける課題の1つの解決策として、IngressLinkをご紹介させて頂きました。F5ではコンテナ、セキュリティはさることながら、アプリケーションに対する昨今の高いニーズに対応できる数々のソリューションをご提案しています。アプリケーションに関する課題がありましたら、是非、F5にお声がけ下さい。