(AKS) Pod の発信元 IP アドレス

AKS Azure

Pod の発信元 IP アドレスに関するメモ。

AKS のネットワーク構成では kubenet 方式(基本)と Azure CNI 方式(高度)が提供されている。

docs.microsoft.com

◆Kubenet (基本) ネットワークの場合、vNet 内外にかかわらず、ノードのプライマリ IP アドレスに NAT 変換される。

docs.microsoft.com

<抜枠>

4.トラフィックの発信元 IP アドレスは、ノードのプライマリ IP アドレスに変換されます。

◆Azure CNI の場合、vNet 内の通信か、vNet→外の通信かで発信元 IP アドレスが変わる。

・vNet 内・・・ポッドの IP

・vNet→外・・・ノードの IP

github.com

<抜枠>
Azure CNI 対応ポッドで発生したトラフィックに対して、外部システムではどのソース IP が認識されますか。
AKS クラスターと同じ仮想ネットワーク内のシステムでは、ポッドの IP が、ポッドからのすべてのトラフィックの発信元アドレスとして認識されます。
AKS クラスター仮想ネットワークの外部にあるシステムでは、ノードの IP が、ポッドからのすべてのトラフィックの発信元アドレスとして認識されます。

2021-04-16

(AKS) AKS クラスターからインターネットへの出力制御

AKS Azure

既定では、AKS クラスターからインターネットへのアクセスは制限されていない。

Azure Kubernetes Service (AKS) でエグレストラフィックを制限する - Azure Kubernetes Service | Microsoft Docs

<抜枠>

既定で、AKS クラスターは、送信 (エグレス) インターネットアクセスが無制限です。

AKS 単体の機能では、インターネットへの出力を制御する機能は無い。

NSG 自体は存在しているが、既定のマネージドサブネットを変更するのはサポート外である。カスタムサブネットでは対応している様子。

Azure Kubernetes Service (AKS) のサポートポリシー - Azure Kubernetes Service | Microsoft Docs

※マネージドサブネットはMC_ResourcegroupMC_Resourcegroup_*の事と思われる

<抜枠>

NSG のカスタマイズは、カスタムサブネット上でのみ行うことができます。マネージドサブネット上またはエージェントノードの NIC レベルで NSG をカスタマイズすることはできません。

Azure の機能でインターネットへ特定の URL に対して出力経路を制限するには、Azure Firewall などの利用を検討する。

Azure Kubernetes Service (AKS) でエグレストラフィックを制限する - Azure Kubernetes Service | Microsoft Docs

<抜枠>

Azure Firewall では、送信先の FQDN に基づいて HTTP と HTTPS の送信トラフィックを制限できます。また、適切なファイアウォール規則とセキュリティ規則を構成し、これらの必要なポートとアドレスを許可することができます。

2021-04-11

(k8s) Pod のトラブルシューティングのログ

AKS Azure k8s

k8s (kubernetes) の Pod で以下のような事象が発生した場合、確認すべきログのメモ

・Pod が起動しない

・Pod が ContainerCreating から先に進まない

・Pod が再起動を繰り返す

・Pod 内のコンテナが開始に失敗するなど

1. 事象確認

コマンド「kubectl get po」

Pod が Ready ではないことや ContainerCreating から先に進んでいないことが分かる。

% kubectl get po

NAME READY STATUS RESTARTS AGE

nfs-client-7ff95d88b-krt2z 0/1 ContainerCreating 0 2d9h

2. 原因調査

コマンド「kubectl get events | grep <Pod 名>」

エラーメッセージと Exit コードを確認する。以下ではボリュームをマウント出来ないことや、Exit コード 32 で終了したことが分かる。

% kubectl get events | grep nfs-client-7ff95d88b-krt2z

72s Warning FailedMount pod/nfs-client-7ff95d88b-krt2z Unable to attach or mount volumes: unmounted volumes=[nfs], unattached volumes=[nfs default-token-7pppr]: timed out waiting for the condition

6m10s Warning FailedMount pod/nfs-client-7ff95d88b-krt2z MountVolume.SetUp failed for volume "nfs-1" : mount failed: exit status 32

コマンド「kubectl describe po <Pod 名>」

本コマンドでも「kubectl get events | grep <Pod 名>」と同様に Pod の Exit コードが確認できる。

コマンド「kubeclt logs -f <Pod 名>」

本コマンドでも Pod のログを確認できる。Exit コードでエラーが発生した原因を確認する際に利用できる場合がある。

% kubectl logs -f nfs-client-7ff95d88b-krt2z

Error from server (BadRequest): container "ubuntu" in pod "nfs-client-7ff95d88b-krt2z" is waiting to start: ContainerCreating

参考書籍

k8s の基礎からトラブルシュート、設計の考え方を学べるとても良い本です。

www.amazon.co.jp

2021-03-27

(ACR) MS Learn コンテナービルドの個人的補足

Azure ACR

以下の学習にあたり、Linux 環境に Docker を入れて学習する場合の補足

Docker を使用してコンテナー化された Web アプリケーションを構築する - Learn | Microsoft Docs

試した環境: Ubuntu 18.04 を Azure 上の VM として利用 / Docker をインストール

<事前準備>

1. Docker のインストールおよび事後作業

https://docs.docker.com/engine/install/ubuntu/

https://docs.docker.com/engine/install/linux-postinstall/

2. Git のインストール

https://git-scm.com/book/ja/v2/%E4%BD%BF%E3%81%84%E5%A7%8B%E3%82%81%E3%82%8B-Git%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB

<Learnの本編>

Unit2

・利用PCのブラウザーからコンテナーに動作確認する場合、Ubuntu VM の NSG のポート(演習では8080) の受信規則は許可しておくこと

既存の Docker イメージを取得し、それをローカルでデプロイする - Learn | Microsoft Docs

Unit4

・Docker file より以下のコマンドでビルド実行時にエラーが発生した場合は、Docker file の記述を見直す事。

docker build -t myapp:v1 .

独自の Web アプリを実行するために Docker イメージをカスタマイズする - Learn | Microsoft Docs

※Docker file の FROMを"FRO"を抜かして"M"のみ記載していたため、以下のようなエラーが出た。

Sending build context to Docker daemon 29.7kB

Error response from daemon: dockerfile parse error line 1: unknown instruction: M

Unit5

・Ubuntu 上で Docker file を編集する場合は vi <ファイル名> を利用した。COPY や notepad コマンドは Windows 前提のため。

演習 - 独自の Web アプリを実行するために Docker イメージをカスタマイズする - Learn | Microsoft Docs

Unit7

・ACR に存在するイメージのバージョンに注意する事。以下のコマンドで、今回はreservationsystem:latest と指定する。

docker tag reservationsystem:latest <registry-name>.azurecr.io/reservationsystem:latest

演習 - Azure コンテナーインスタンスに Docker イメージをデプロイする - Learn | Microsoft Docs

※参考: 別の Learn の演習で reservationsystem:v1で作成していたため、上記のコマンドをそのまま実行したところ以下のエラーが出た。

The image 'xxxx.azurecr.io/myapp:latest' in container group 'instance' is not accessible. Please check the image and registry credential.

2021-03-19

(メモ) Teamsを条件付きアクセスで設定する際の注意点

サマリ

・条件付きアクセスで「Microsoft Teams」だけを条件付きアクセスのブロックから除外しても、Teamsはブロックされる。

・Teams を利用する場合は「Office 365」もブロックから除外すること。あるいは、必要な機能に応じて「SharePoint」や「Exchange」も除外対象に追加する。

前提:

・条件付きアクセスで全てのアプリをブロックが設定されている

f:id:justaday:20210319234219p:plain

上記ポリシーに加えて、以下のポリシーを加えて除外設定を行う。

1.Teamsがブロックされる例

・Teams のみを除外

f:id:justaday:20210319233938p:plain

2.Teamsがブロックされない例

・Office 365を除外

f:id:justaday:20210319234351p:plain

詳細

・条件付きアクセスポリシーを利用する上ではTeamsは他のOffice365サービスと依存関係がある。例えば、Teams がファイル共有はSharePointと機能の依存性があるため、SharePointがブロックされてしまうとTeamsの機能が利用できない。

f:id:justaday:20210319223905p:plain

・事前バインディングポリシーと言い、Teamsなどのアプリにアクセスする前にSharePointなど関連するアプリにアクセスを可能にさせる必要がある。

条件付きアクセスのサービス依存関係 - Azure Active Directory | Microsoft Docs

事前バインディングポリシー適用では、ユーザーが呼び出し元のアプリにアクセスする前に依存サービスポリシーを満たす必要があります。たとえば、ユーザーが MS Teams にサインインする前に SharePoint ポリシーを満たす必要があります。

f:id:justaday:20210319222949p:plain

以上

2021-03-04

(各種リンク) Azure VMのネットワーク状況の確認方法

1. 仮想マシンのメトリック

VM のネットワークインターフェースで送受信したデータ量を確認可能。

Azure Monitor を使用して Azure 仮想マシンを監視する - Azure Monitor | Microsoft Docs

2.Log Analyticsエージェント

VM に対しパフォーマンスカウンターを構成し、VMのネットワークに関する各種カウンターを収集可能。

Azure Monitor で Log Analytics エージェントを使用して Windows と Linux のパフォーマンスデータソースを収集する - Azure Monitor | Microsoft Docs

3. Azure Monitor の診断拡張機能

Linux VMの場合、VMへの拡張機能である Linux Diagnostic Extensions が存在する。

VMのネットワークインターフェイスで送受信したパケット数やデータ量を確認可能。

Azure Compute - Linux Diagnostic Extension 4.0 - Azure Virtual Machines | Microsoft Docs

2021-02-24

(メモ) Azure 上の障害、メンテナンス確認方法

Azure 監視

1.サービス正常性

Azure portalから利用できる機能。

・各種 Azure サブスクリプション配下のリソース (VM、SQL Database、Storageなど) で問題が発生している場合に、本機能で確認ができる。

・後述のリソース正常性は個別のVMなどの障害を検知するのに対し、サービス正常性はより広い障害やメンテナンスを確認する機能である。

・本機能を利用するためには、サブスクリプションレベルで"閲覧者"権限が必要であることは注意。

・メールなどにアラート通知も可能。

Azure Portal を使用したサービス正常性通知の表示 - Azure Service Health | Microsoft Docs

<引用ここから>

Service Health はお使いのリソースに影響を及ぼす可能性のある次の 4 つの種類の正常性に関するイベントを追跡します。

サービスの問題 - ユーザーに今すぐ影響を及ぼす Azure サービスの問題。
定期的なメンテナンス - お使いのサービスの可用性に将来影響を及ぼす可能性のある今後のメンテナンス。
正常性に関する勧告 - ユーザーが注目する必要のある Azure サービスの変化。例としては、Azure の機能が非推奨となることやアップグレードの要件 (サポートされている PHP フレームワークへのアップグレードなど) が挙げられます。
セキュリティに関する勧告 - Azure サービスの可用性に影響する可能性があるセキュリティ関連の通知または違反。