AKSの基礎を理解するシリーズ

AKS上のアプリケーションのアップグレード / AKSの基礎を理解するシリーズ Part. 12 この記事の内容 YAMLファイルを編集して kubectl apply で変更を反映する基本的なアップグレード手順 ローリングアップデートの仕組みと、kubectl rollout によるロールバックの方法 kubectl patch コマンドを使ったピンポイントな設定変更の方法 Helm を使ったアプリケーション（WordPress + MariaDB）のアップグレード手順 Kubernetes Secret からパスワードを取得してHelmコマンドに渡す方法 YAMLファイルを編集してアップグレードする アプリケーションのデプロイ まず、ハンズオン用のディレクトリに移動し、GuestbookアプリケーションをYAMLファイルから展開します。 kubectl apply -f guestbook-all-in-one.yaml 展開後、Serviceの状態を確認します。このタイミングでは、フロントエンドのServiceにExternal IPが割り当てられていないことを確認できます。 kubectl get service サービスタイプの変更（LoadBalancerへの切り替え） YAMLファイルを編集して、フロントエンドのServiceタイプを変更します。 code guestbook-all-in-one.yaml エディタが開いたら102行目付近にあるフロントエンドのServiceの定義を探します。タイプが指定されていないため ClusterIP になっている箇所を探し、以下のようにアンコメントして LoadBalancer を指定します。 type: LoadBalancer ファイルを保存して閉じた後、再度 kubectl apply を実行します。 kubectl apply -f guestbook-all-in-one.yaml 実行結果に service/frontend configured と表示されれば、フロントエンドのServiceの構成が変更されています。再度 kubectl get service を実行すると、External IPが割り当てられ、タイプが LoadBalancer に変わっていることを確認できます。 ローリングアップデートとロールバック イメージのバージョンダウングレード 次に、フロントエンドのコンテナイメージのバージョンを変更する操作を試みます。YAMLファイルを再度編集し、127行目付近にあるイメージのタグを変更します。 # 変更前 image: gcr.io/google-samples/gb-frontend:v4 # 変更後 image: gcr.io/google-samples/gb-frontend:v3 保存して、再度適用します。 ...

AKSノードのスケーリング / AKSの基礎を理解するシリーズ Part. 12 この記事の内容 AKSノードプールの手動スケーリングで、ノード数を2台から1台に減らす方法を確認します リソース不足によりPodが Pending 状態になる仕組みを実際に体験します Azure CLIを使ってクラスターオートスケーラーを有効化し、ノードを自動的にスケールアウトさせます ノードが増えることでPendingだったPodが起動する流れを観察します ハンズオン後の後片付けとして、オートスケーラーの無効化とノード数の固定手順を確認します ノードプールのスケーリング設定を確認する AzureポータルでAKSクラスターを開き、設定 > ノードプール から「agentpool」を選択します。現在はノード数2で稼働しています。 ノードプールの設定画面には「スケーリング」セクションがあり、ここで手動または自動のスケーリングを選択できます。 手動スケーリングでノード数を1に減らす まず手動スケーリングを選択してノード数を1に設定し、動作を確認します。設定を変更すると、プロビジョニングの状態が「スケーリング」となります。完了までおよそ5分ほどかかります。 スケーリングが完了すると、1ノードが「準備完了」の状態になります。 1ノードの状態でアプリケーションをデプロイする ノードが1台になったところで、ゲストブックアプリケーションをデプロイして動作を確認します。Cloud Shellを起動し、ハンズオン用のディレクトリに移動します。 cd handson/azure/chapter04 kubectl create -f guestbook-all-in-one.yaml リソース不足でPodをPending状態にする デプロイ後、バックエンドのRedisレプリカ数を増やして、1台のノードではリソースが足りない状態を意図的に作ります。 kubectl scale deployment redis-replica --replicas=5 スケール後にPodの状態を確認します。 kubectl get pods 5台では問題なく動いてしまったため、さらにレプリカ数を増やします。 kubectl scale deployment redis-replica --replicas=10 再度状態を確認すると、一部のPodが Pending になっています。 kubectl get pods Pending はリソースが不足していて起動できない状態を意味します。単純に待っても解消されるものではなく、ノードを増やしてリソースを確保する必要があります。 Azure CLIでオートスケーラーを有効化する スケールアウトの方法は2つあります。 ポータルからノードプールのスケーリング設定を変更する Azure CLIを使用する 今回はCLIで実施します。az aks nodepool update コマンドを使ってクラスターオートスケーラーを有効化します。 az aks nodepool update \ --enable-cluster-autoscaler \ --resource-group RG-HANDSON-AKS \ --cluster-name handson-aks \ --name agentpool \ --min-count 1 \ --max-count 2 このコマンドで、最小1台・最大2台のオートスケーリングが有効になります。設定完了後、ノードの状態を監視します。 ...

Podのスケーリング / AKSの基礎を理解するシリーズ Part. 12 この記事の内容 Kubernetesでは kubectl scale コマンドを使ってPodの数を手動で増減できます Podは複数のノードにまたがってスケールアウトされます Horizontal Pod Autoscaler（HPA）を使うことで、CPU使用率に応じた自動スケーリングが可能です 負荷テストツール「hey」を使ってHPAの動作を実際に確認できます スケールインは負荷が下がってからしばらく時間がかかります サンプルアプリケーションのデプロイ まず、スケーリングを試すためのサンプルアプリケーション（Guestbook）をデプロイします。Cloud Shellを開き、以下のコマンドを実行します。 cd chapter04 kubectl create -f guestbook-all-in-one.yaml デプロイが完了したら、サービスの状態を確認します。 kubectl get service このサンプルではフロントエンドのサービスタイプが ClusterIP になっており、外部からアクセスできない状態です。外部公開するためにサービスのタイプを変更します。 サービスを外部公開する（LoadBalancer に変更） kubectl edit コマンドでサービスを編集します。 kubectl edit service frontend viエディターが起動しますので、type: ClusterIP の部分を type: LoadBalancer に変更します。 i キーでインサートモードに入る ClusterIP を LoadBalancer に書き換える Esc キーを押す :wq! と入力してEnterキーを押す 編集後、External IPが付与されるまでウォッチで確認します。 kubectl get service -w しばらくするとフロントエンドに External IP が付与されます。そのIPアドレスにブラウザでアクセスすると、Guestbookアプリケーションが動作していることを確認できます。 Podの状態を確認する 現在のPodの状態を確認します。 kubectl get pods デフォルトの状態では、フロントエンドのPodが3つ、バックエンド（マスター＋レプリカ）が3つ動いています。 ...

Helmで展開したWordPressの確認 / AKSの基礎を理解するシリーズ Part. 9 この記事の内容 HelmでAKSに展開したWordPressとMariaDBのPod状態を確認します StatefulSetとDeployment（ReplicaSet）の違いについて解説します PersistentVolumeClaimとAzureディスクの関係を確認します Helmのステータス確認コマンドと外部公開の状態を確認します Helm環境の削除とPVCのクリーンアップ手順を紹介します Podの状態確認 まず、HelmでデプロイしたWordPressとMariaDBのPodが正常に動作しているかを確認します。 kubectl get pods このコマンドを実行すると、WordPressのPodとMariaDBのPodが動作していることを確認できます。 StatefulSetとDeploymentの違い WordPressはReplicaSetとして管理されているのに対し、MariaDBはStatefulSetとして管理されています。この2つの違いは何でしょうか。 **Deployment（ReplicaSet）**は、状態を持たないステートレスなワークロードを管理します。Podを削除・再作成しても問題がない、いわゆる「使い捨て可能」なコンテナに適しています。WordPressのようなアプリケーション層がこれに該当します。 StatefulSetは、状態を持つステートフルなワークロードを管理します。データベースのように「中身が消えてはいけない」ものに使われます。MariaDBはデータを永続的に保持する必要があるため、StatefulSetとして管理されます。 Kubernetesのダッシュボードやワークロードビューでも、それぞれの分類が確認できます。 ReplicaSet（Deployment） → WordPress StatefulSet → MariaDB PersistentVolumeClaimの確認 MariaDBがStatefulSetである理由は「永続的なデータ保存」にあります。StatefulSetには永続ボリューム（PersistentVolume）が紐付けられており、Podが削除されてもデータが消えない仕組みになっています。 MariaDBのStatefulSetの定義を確認してみます。 kubectl get statefulset kubectl get statefulset maria-db -o yaml > mariadb.yaml cat mariadb.yaml 定義ファイルの中に persistentVolumeClaim という記述があります。これは「永続的に使えるボリュームをください」というリクエストです。今回は8GBのファイルシステムが要求されており、アクセスモードは ReadWriteOnce（単一ノードからの読み書き）に設定されています。 StorageClassの確認 アクセスモードに応じて、AKSは適切なAzureのストレージサービスを自動的に選択してPodに割り当てます。現在のAKSクラスターで利用可能なストレージの種類は以下のコマンドで確認できます。 kubectl get storageclass AKS環境では Azure Files や Azure Managed Disk などのストレージクラスが利用可能です。 現在使用中のPersistentVolumeClaimは以下のコマンドで確認できます。 kubectl get pvc 今回は2つのボリュームが使用されていることが確認できます。 Azureポータルでのディスク確認 AKSのインフラストラクチャーリソースグループを確認すると、KubernetesのPVC要求に従って自動的に2つのディスクが作成されていることがわかります。これらのディスクはPodにアタッチされており、コンテナが削除されてもデータは消えない永続的なリソースです。 ディスクの「管理者」を確認すると、VMSS（Virtual Machine Scale Set）の特定のノードに紐付いていることが確認できます。この割り当ては自動的に行われます。 ...

この動画では、HelmチャートをAKS（Azure Kubernetes Service）クラスタに適用してWordPressをデプロイする手順をステップバイステップで解説しています。 Helmは「Kubernetesのパッケージマネージャー」とも呼ばれ、複雑なアプリケーションのデプロイを大幅に簡略化できる強力なツールです。本シリーズの第8回となる今回は、実際にWordPressというリアルなアプリケーションを題材にすることで、Helmの実践的な使い方を体験しながら学べる構成になっています。 「AKSは知っているけれどHelmはまだ使ったことがない」「Kubernetesのマニフェスト管理が煩雑に感じている」という方に特におすすめです。シリーズを通じてAKSの基礎から応用まで丁寧に積み上げてきた内容なので、Part. 1から順に視聴するとより理解が深まります。ぜひ動画で実際の操作を確認してみてください。

デモアプリケーションの削除 / AKSの基礎を理解するシリーズ Part. 7 この記事の内容 kubectl delete コマンドを使って、マニフェストファイルからデプロイしたリソースを削除する手順を解説します 削除後に kubectl get all で確認する方法を紹介します Azure ポータル上のワークロード表示でも削除が反映されることを確認します AKS の基盤となるインフラストラクチャリソースグループ（Public IP、ロードバランサー、NSG）がどのように変化するかを確認します Cloud Shell の起動と作業ディレクトリへの移動 まず Azure Portal から Cloud Shell を起動します。作業しやすいようにウィンドウを広げておきましょう。 次に、デプロイ時に使用したマニフェストファイルが置いてあるディレクトリへ移動します。 cd handson-kubernetes-azure/chapter02 kubectl delete でリソースを削除する デプロイ時に使用した azure.yaml（マニフェストファイル）を指定して、リソースを削除します。 kubectl delete -f azure.yaml このコマンドを実行することで、マニフェストに記載されたすべてのリソースが削除対象となります。 削除の確認 削除が完了したかどうかを確認するには、以下のコマンドを実行します。 kubectl get all 実行直後はまだ azure-vote-front が Terminating の状態で表示されることがあります。これは削除処理の途中であるためです。もう一度コマンドを実行すると、すべてのリソースが消えていることが確認できます。 Azure ポータルでの確認 Azure ポータルの AKS リソース → ワークロード の画面を確認すると、デプロイしていたアプリケーションがすべて消えていることがわかります。 インフラストラクチャリソースグループへの影響を確認する AKS には、Kubernetes のリソースを支える インフラストラクチャリソースグループ が自動的に作成されています。アプリケーションを削除すると、このリソースグループにも自動的に変更が反映されます。 確認方法は、AKS リソースの プロパティ から「インフラストラクチャリソースグループ」のリンクを開きます。 ...

AKSクラスタとデモアプリケーションがAzureにどのように展開されたのかをKubernetes内部も含めて確認 この記事の内容 AKSのネットワーク構成（kubenet）において、PodネットワークとサービスネットワークがAzure VNetとどのように分離されているかを解説します デプロイメント・レプリカセット・サービスといったKubernetesリソースの役割と相互関係を確認します YAMLファイルの定義内容とAKSポータル画面の表示がどのように対応しているかを照らし合わせます フロントエンドとバックエンドの2コンポーネント構成アプリケーションが、内部でどのように通信しているかを追います kubectl get all コマンドで全リソースをまとめて確認する方法を紹介します AKSのネットワーク構成（kubenet） 今回は規定の設定でAKSクラスタを作成したため、ネットワーク構成のタイプは kubenet になっています。kubenetにはほかにもタイプがあり、選択によって構成が変わりますが、今回は最もシンプルな構成です。 kubenetでは、KubernetesクラスタはNAT（ネットワークアドレス変換）を介してAzureの仮想ネットワーク（VNet）側と通信します。つまり、AzureのVNetとKubernetes内部のネットワークは完全に切り離されており、NATによって相互通信が実現されています。 Kubernetes内部には、大きく2つのネットワークが存在します。 ネットワーク CIDRブロック サービス用ネットワーク 10.0.0.0/16 Pod用ネットワーク 10.244.0.0/16 この設定はAKSのネットワークプロファイルから確認できます。 種 P S 類 o e d r v C i I c D e R C I D : R k : : u b 1 1 e 0 0 n . . e 2 0 t 4 . 4 0 . . 0 0 . / 0 1 / 6 1 6 Pod用ネットワークの中にPodが配置され、そのPodの中で1つ以上のコンテナが動作します。概念的には、Podは1つの仮想マシンに近いイメージで捉えると理解しやすいです。PodはIPアドレスと名前を持ちます。 ...

この記事の内容 AKSクラスターを展開すると、Azureのバックエンドにどのようなリソースが自動作成されるかを解説します 仮想ネットワーク、サブネット、Virtual Machine Scale Set（VMSS）の構成を確認します ロードバランサーとパブリックIPアドレスを介した外部アクセスの仕組みを解説します NSG（ネットワークセキュリティグループ）とルートテーブルの役割を確認します AzureポータルでAKSのインフラストラクチャリソースグループを実際に見ながら理解を深めます AKSクラスター展開時のAzureリソース全体像 AKSクラスターをデプロイすると、Azureのバックエンド側にさまざまなリソースが自動的に作成されます。展開された構成を確認する前に、まずAzure基盤側でどのようなサービスが作られているかを見ていきましょう。 全体の構成は以下のようになっています。 Azureの仮想ネットワークが作成されます その中にサブネットが作られます AKSはクラスターのためスケールアウトできるように、**Virtual Machine Scale Set（VMSS）**が作成されます。ノード数は設定に応じて増減します VMSSのインスタンスがサブネットに接続されます 外部からアプリケーションにアクセスできるようにロードバランサーとパブリックIPアドレスが作成されます 通信を制御するためにNSG（ネットワークセキュリティグループ）とルートテーブルがサブネットに紐付けられます インフラストラクチャリソースグループの確認 AzureポータルでAKSのサービス（Kubernetesサービス）を開き、プロパティを見てみると「インフラストラクチャリソースグループ」という項目があります。 このリソースグループが、AKSクラスターを実際に動かしているAzureのサービス群が格納されている場所です。中には以下のようなリソースが含まれています。 Virtual Machine Scale Set（VMSS） 仮想ネットワーク NSG・ルートテーブル マネージドID パブリックIPアドレス ロードバランサー これらすべてが連携して、AKSクラスターを動作させています。 仮想ネットワークとサブネットの構成 仮想ネットワークのアドレス空間は以下のように設定されています。 仮 サ 想 ブ ネ ネ ッ ッ ト ト ワ （ ー A ク K : S 1 s 0 u . b 2 n 2 e 4 t . ） 0 : . 0 1 / 0 1 . 2 2 2 4 . 0 . 0 / 1 6 サブネットの「接続デバイス」を確認すると、VMSSのインスタンスが2台接続されていることが確認できます。 ...

AKSクラスタへのデモアプリケーションの展開 — AKSの基礎を理解するシリーズ Part. 4 この記事の内容 Azure Cloud Shellを使ってGitHubからサンプルコードをクローンする手順を紹介します kubectl create -f コマンドを使い、YAMLファイルからKubernetesリソースを一括展開する方法を解説します kubectl get pods や --watch オプションを使ったPod状態の確認方法を説明します LoadBalancerサービスで発行された外部IPを使ってアプリにアクセスする流れを確認します デモアプリとして投票アプリ（Azure Voting App）を動作確認し、フロントとバックの2層構成を体験します GitHubからサンプルコードをクローンする Cloud Shellを開いたら、まずGitHubに用意されているハンズオン用リポジトリをクローンします。 git clone https://github.com/MicrosoftPublishing/HandsOnKubernetesOnAzure クローンが完了したら、デモアプリケーションの定義ファイルが格納されているディレクトリへ移動します。 cd HandsOnKubernetesOnAzure/chapter02 このディレクトリの中に azure.yaml というファイルがあります。このYAMLファイルにアプリケーションのリソース定義が記述されています。 YAMLファイルの中身を確認する（任意） 中身が気になる方は、Cloud Shellのエディタで確認できます。 code azure.yaml コマンドを実行するとエディタが立ち上がり、Kubernetesリソースの定義を参照できます。確認が終わったら、変更を保存せずにエディタを閉じてください。 アプリケーションを展開する では、実際にアプリケーションをAKSクラスタへ展開します。kubectl create コマンドに -f オプションでYAMLファイルを指定するだけです。 kubectl create -f azure.yaml このコマンドを実行すると、YAMLファイルに定義された以下の4つのリソースがまとめて作成されます。 リソース種別 名前 Deployment apps-azure-vote-back Service apps-azure-vote-back Deployment apps-azure-vote-front Service apps-azure-vote-front フロントエンドとバックエンドが連携する2層構成のアプリケーションです。 Podの稼働状態を確認する アプリを展開したら、Podが正常に動いているか確認しましょう。 kubectl get pods azure-vote-front と azure-vote-back の2つのPodが表示され、STATUS が Running になっていれば正常です。 ...

AKSクラスタへのCloudShellからの接続 / AKSの基礎を理解するシリーズ Part. 3 この記事の内容 Azure Cloud ShellからAKS（Azure Kubernetes Service）クラスタに接続する方法を解説します Cloud Shellを初めて使う場合はストレージアカウントのマウントが必要です az aks get-credentials コマンドでクレデンシャルを取得します 取得したクレデンシャルは ~/.kube/config にカレントコンテキストとして保存されます kubectl get nodes コマンドでノードの一覧を取得し、接続を確認します Azure Cloud Shellを開く AzureポータルのAKSクラスタにCloud Shellから接続するには、まずAzure管理ポータル上部にあるCloud Shellのアイコンをクリックします。 Cloud Shellを初めて利用する場合は、ストレージのマウントが必要です。画面の指示に従ってストレージアカウントを作成してください。すでにCloud Shellを使ったことがある方は、そのまま利用できます。 ストレージの準備ができると、Bashのシェルが立ち上がります。 クレデンシャルの取得 Cloud ShellからAKSクラスタを操作するには、まずクレデンシャルを取得する必要があります。az aks get-credentials コマンドを使い、対象クラスタのリソースグループ名とクラスタ名を指定して実行します。 az aks get-credentials --resource-group RGHandsOnAKS --name HandsOnAKS このコマンドを実行すると、~/.kube/config にAKSクラスタのクレデンシャルがカレントコンテキストとして保存されます。これにより、kubectl コマンドでAKSクラスタを操作できる状態になります。 ノードの確認 クレデンシャルの取得が完了したら、kubectl get nodes コマンドを実行してクラスタのノード一覧を取得します。 kubectl get nodes 正しく接続できていれば、ノードの一覧が表示されます。これでCloud ShellからKubernetesクラスタへの接続が確認できました。 まとめ AzureポータルのCloud ShellからAKSクラスタに接続するには、以下の手順で行います。 Azure管理ポータル上部のCloud Shellアイコンをクリックし、Bashを起動する 初回利用時はストレージアカウントを作成してマウントする az aks get-credentials コマンドでリソースグループ名とクラスタ名を指定してクレデンシャルを取得する kubectl get nodes コマンドでノードの一覧を取得し、接続を確認する Cloud Shellはブラウザから直接利用できるため、ローカル環境へのツールインストールが不要です。AKSクラスタへのアクセスをすぐに試したい場合に非常に便利な方法です。 ...

AKSクラスターの基本的な確認方法 — AKSの基礎を理解するシリーズ Part. 12 この記事の内容 Azureポータルから作成済みAKSクラスターへのアクセス方法 クラスター概要ページで確認できる基本情報（APIサーバーアドレスなど） ノードプールの設定内容と実行可能な操作 クラスター構成における認証・認可の選択肢 Azure Monitorとの連携による監視機能の概要 Azureポータルでクラスターを確認する AKSクラスターを作成したら、まずポータルからその内容を確認してみましょう。 作成完了後に表示される画面で「リソースに移動」ボタンをクリックすると、作成したクラスターのページに直接移動できます。あるいは、ポータルの検索バーで「AKS」と入力してサービス一覧に移動し、作成したクラスターを選択する方法でも同じページに到達できます。 クラスターの概要ページ クラスターのトップページでは、以下のような基本情報を確認できます。 クラスターの名前 APIサーバーのアドレス その他の基本的なステータス情報 APIサーバーのアドレスが表示されているため、「このクラスターのAPIはここにある」ということが一目でわかります。 また、「Kubernetesリソース」のセクションでは、クラスター内で動作しているリソースを確認することができます。実際にアプリケーションをデプロイする際などに活用するセクションですが、その詳細は後続の回で扱います。 ノードプールの確認と操作 「設定」メニューの中にある「ノードプール」では、作成したノードプールに関する詳細情報を確認できます。 項目 内容 稼働状況 現在のノードプールの状態 Kubernetesのバージョン 使用しているk8sのバージョン ノードのサイズ VMのサイズ オペレーティングシステム 使用しているOS ノードプールを選択すると、以下の操作も実行できます。 Kubernetesのアップグレード ノードイメージの更新 ノードプールのスケーリング なお、AKSのノードは内部的にはVirtual Machine Scale Set（VMSS）によって管理されており、その詳細もポータルから確認できるようになっています。 クラスター構成の設定 「クラスター構成」では、以下のような項目を設定できます。 Kubernetesのバージョン AKSの価格レベル 認証・認可の設定 Azureらしい特徴のひとつが、認証・認可の柔軟な設定です。 既定では、Kubernetes RBACを使用したローカルアカウントが選択されていますが、以下のような選択肢も簡単に切り替えることができます。 Azure AD認証のみ使用する Azure ADをRBACも含めてすべてに使用する Microsoft Entra ID（旧Azure AD）との統合がポータルから手軽に選択できる点は、Azureならではの利便性です。 監視（Azure Monitor連携） 「監視」のセクションでは、Azure Monitorと連携したクラスターの監視設定が行えます。 「分析情報」をクリックするだけで監視を構成し、クラスターの状態をダッシュボードで分析できるようになります。この機能についても後の回で詳しく扱います。 まとめ 本記事では、作成済みのAKSクラスターをAzureポータルで確認する基本的な方法を紹介しました。 ポータルの「リソースに移動」または検索からクラスターページに移動できます 概要ページではAPIサーバーアドレスなどの基本情報を確認できます ノードプールではバージョンやVMサイズの確認、スケーリングなどの操作が可能です クラスター構成では認証方式としてAzure AD統合を簡単に選択できます 監視はAzure Monitorとの連携で設定できます まずはどのようなメニューがあるかをひと通り眺めておくと、後の操作をスムーズに進めることができます。 ...