Windows Server Community Meetup #04の資料「Windows Admin Center 2110」を公開します。

Windows Server Community Meetup #04の資料「Windows Admin Center 2110」を公開します。

Windows Admin Center 2110 from Norio Sashizaki

2022/04/29追記

こちらに記載した接続リストの挙動が治ったようです。別稿にて確認結果を記載します。

サービス アカウント ベアラー トークン/サービス アカウント トークン認証 で Azure Arc の Kubernetes クラスター を確認

Azure Arc に Kubernetes クラスターをつないだのですが、Kubernetes リソース（プレビュー）でこんな画面が表示されます。

"サービス アカウント ベアラー トークン"ってなんだろうと、リンクをクリックしました。

クラスター接続を使用して Azure Arc 対応 Kubernetes クラスターに接続する

にたどり着きました。"サービス アカウント トークン認証オプション"のことを指していると理解してます。

ということで、

• 前提条件
  古い azure-cli の削除、curl のインストール、Azure へのログインも実施
• クラスター接続機能を有効にする
  
• サービス アカウント トークン認証オプション
• クラスターにアクセスする
  事前準備として、kubectl のインストール、kube-configの配置を実施
• Azure Portal のにトークンを貼り付けた後は、こうなった

について確認していきます。

注）クラスター接続を使用して Azure Arc 対応 Kubernetes クラスターに接続する　は、WSL か、Linuxなど、base64とsedが使える環境を想定しています。また変数の設定方法が、Linux/UNIX系だと気づくのに時間がかかってしまいました。皆様も同じ轍を踏まないようにご注意ください。今回は、Ubuntu な仮想マシンを使って確認しました。

前提条件

古い azure-cli の削除、curl が入っていなかったのでインストールを実行します。

azure-cli をインストールします。

connectedk8s Azure CLI 拡張機能を追加します。

Azure へのログインします。デバイスコードをオプションで指定してます。

サブスクリプション切り替え、変数設定、kubectl の実行形式を入手します。

実行許可を付けてから、/usr/local/binへ移動します。kubectl のバージョンも確認します。

このあと、kube-config が必要になるので、.kube フォルダーを作成し、scpなどでコピーしておきます。

クラスター接続機能を有効にする

az connectedk8s enable-features --features cluster-connect -n $CLUSTER_NAME -g $RESOURCE_GROUP

により、クラスター接続機能を有効化します。（キレイに確認できていなかったときは、ここで kube-config が必要でしたね）

サービス アカウント トークン認証オプション、クラスターにアクセスする

あとは、サービス アカウント トークン認証オプションを粛々と進めます。
なお、

kubectl create serviceaccount admin-user

kubectl create clusterrolebinding admin-user-binding --clusterrole cluster-admin --serviceaccount default:admin-user

は、キレイに確認できていなかったときに作成済みです。よって、下記画面ショットではエラーとなっていますことご了承ください。

クラスターにアクセスする

Proxy まで立ち上げたら、別の Terminal から

kubectl get pods

を実行して確認します。

Azure Portal のにトークンを貼り付けた後は、こうなった

サービス アカウント トークン認証オプションが構成できましたので、$TOKENから文字列を引っこ抜きまして、下記画面に貼り付けます。

無事に色々見えるようになりました！

下記は、まだ設定されていないので表示無しです。

Azure Kubernetes Service の Kubernetes クラスターで Kubernetes を更新

Azure Kubernetes Service の Kubernetes クラスター（ワークロード用）で Kubernetes を更新できますね。

[今すぐ更新]をクリックすると、更新が開始します。

数分間待つと完了しますね。

こういう機能もあるということで、ご理解ください。

AKS ランタイム on Azure Stack HCI/Windows Server の AKS ランタイムをバージョンアップ

AKS ランタイム on Azure Stack HCI/Windows Server を入れてみてから、すでに2回目のバージョンアップが入ってますので、見ていきます。
※初めてのバージョンアップ例も画面キャプチャしていました。せっかくなので新しいほうでご紹介します。

[Azure Kubernetes サービス]→[プラットフォームの管理]→[ホストの設定]の順にクリックします。更新があると下記のような感じになります。

真ん中のチェックボックスにチェックします。そうすると[今すぐ更新]がクリック可能になります。

[今すぐ更新]をクリックし、更新を進めます。

しばらくすると完了します。

[完了]をクリックしておしまいです。

aks-management-cluster-1-control-plane がライブマイグレーションしてくれなかった

S2D 環境のパッチ適用で、クラスター対応更新を行いました。が、aks-management-cluster-1-control-plane がライブマイグレーションしてくれなかったせいで、パッチ適用処理が途中止まってしまいました。

ライブマイグレーションしなかった情報を確認しました。

で、イベント ID などから調べてみました。下記情報から、ISO ファイルのマウントが原因であるかもと思いました。

記憶域スペースダイレクト(S2D)環境にてライブマイグレーションが行われない

さっそく試してみたところ、ライブマイグレーションできました。。。

でも、Kubernetes クラスターのコントロールプレーンとロードバランサーは、ISO ファイルをマウントしたままでもライブマイグレーションできているのですが、なんでだろう。。。
※aks-management-cluster-1-control-planeと同じように、ISO ファイルは、CSV 上に配置されています。

こんなこともあるぐらいで、参考になれば幸いです。

AKS on Azure Stack HCI というか AKS Runtime on Windows Server がクラウドと同期しない

こんな画面のまま、AKS Runtime on Windows Server がクラウドと同期しなくなりました。こんな画面になってました。作成していた Kubernetes クラスターも見えなくなりました。

Get-AksHciBillingStatus

を実行したところ、

Error on Azure Kubernetes Service on Azure Stack HCI Error Fetching Billing Information

にあるような

: context deadline exceeded (Client.Timeout exceeded while awaiting headers)]

というエラーが発生してました。

いろいろ調べたのですが、AKS コントロールプレーンの IP アドレスがいなくなっており、+1した IP アドレスがあるのみ。kubeconfig-mgmt の IP アドレスを書き換えても効果なし。ということで、

Azure Kubernetes Service on Azure Stack HCI を再起動、削除、または再インストールする

に従って、AKS を再起動してみました。具体的には

Restart-AksHci

を AKS が動作していた Windows Server 2019 Storage Spaces Direct のノードで管理者権限付き PowerShell から実行します。

AKS 自体は、Get-AksHciBillingStatus でも正常に戻りました。が、いたはずの Kubernetes クラスターは、削除された模様。。。

AKS on Azure Stack HCI というか AKS Runtime on Windows Server を再起動したんです

AKS Runtime on Windows Server をホストしている物理サーバー群を法定停電で停止しました。

法定停電後、AKS Runtime on Windows Server を再起動しましたが、なかなか興味深い挙動でした。

まず、法定停電前に、AKS 用、Kubernetes クラスターとして動作していた仮想マシンは、下記の通り。

• aks-management-cluster-1-control-plane-0-141c3a0f
• my-workload-cluster01-control-plane-4qf4q-237537bf
• my-workload-cluster01-load-balancer-egdxz-2f3c9cef
• nodepoollinux01-md-5njns-c2797ac5
• nodepoollinux01-md-788f7-6fad5b20
• nodepoollinux01-md-8hkp6-c38dee6b
• nodepoollinux01-md-smd89-8ed13bb5

AKS on Azure Stack HCI クラスターの停止と再起動

に従って、クラスターを停止させました。この後、Storage Spaces Direct を構成している物理サーバーをシャットダウン。

法定停電が完了後は、

AKS on Azure Stack HCI クラスターの停止と再起動

にしたがってというか、クラスターが起動すると AKS も起動します。

※aks-management-cluster-1-control-plane 仮想マシンは、自動起動になっていませんが、ちゃんと起動してくれます。が、実際には同じ仮想マシンでは無いのですが。

AKS 用、Kubernetes クラスターとして動作していた仮想マシンを見てみると、仮想マシン名は異なりますねー。

• aks-management-cluster-1-control-plane-vx8jh-1d5eb68c
• my-workload-cluster01-control-s7zcf-2qks7-be26095d
• my-workload-cluster01-load-balancer-uqpzj-5d5e4d67
• nodepoollinux01-md-gztd2-46wp7-42239ab2
• nodepoollinux01-md-gztd2-dqgfl-9db9e7dc
• nodepoollinux01-md-gztd2-rg7nc-4fbdb454
• nodepoollinux01-md-gztd2-wd5xk-b625350b

Windows Admin Center 2110で Azure Kubernetes Service に Kubernetes クラスターをデプロイ

Windows Admin Center 2103.2で Azure Kubernetes Service をデプロイ　その2.4 やっとできた　の続き

公式の手順は、

クイック スタート:Windows Admin Center を使用して Azure Stack HCI 上に Kubernetes クラスターを作成する

にありますので、参考にしてください。

デプロイ対象は、Windows Server 2019 Storage Spaces Direct です。厳密には、認定ハードウェアでは無いので、Azure Stack HCI では無いです。

Azure Kubernetes Service に Kubernetes クラスターをデプロイする前に、Active Directory と SSO するためのファイルを作成します。具体的な手順は、下記にあります。
※パスワードが含まれるので、実際の構築手順は画面無しです。
　また、この方法で作成すると、パスワードの有効期間は、AD のグループポリシーに順じます。ご注意ください。

• API サーバー AD アカウントと keytab ファイルを作成する

Windows Admin Center で、 Kubernetes クラスターをデプロイします。
※ PowerShell による方法は、AKS on Azure Stack HCI に対して Active Directory シングル サインイン資格情報を使用する に記載があります。必要に応じて参考にしてください。

ではデプロイを見ていきます。

[クラスターを追加]をクリックします。

少なくとも、Kubernetes クラスター用仮想マシンとして、16GBのメモリ、CSV に10GBの空き領域が必要であることがわかります。[次のステージ: 基本]をクリックします。

まず、Azure サブスクリプション、リソースグループを選択します。AKS 構築時に使ったものと同じにしています。

ホストユーザー名のパスワードを入力するとチェックが走ります。

Kubernetes クラスターの名称、コントロールプレーンとロードバランサーのサイズ等を設定します。これが先ほど必要と書かれていた16 GB メモリというわけです。

[次のステージ: ノードプール]をクリックします。

ノードプールが全くないので、[ノードプールを追加する]をクリックします。

ノードプール名、ノードサイズ、ノード数などを指定します。

[追加]をクリックします。

[次のステージ: 認証]をクリックします。

ここで、Active Directory での認証を指定します。"AD 認証"を有効化し、"APIサーバーのサービスプリンシパル名"、keytab ファイルのアップロード、"クラスター管理グループまたはユーザー名"を指定します。冒頭で記載した、Active Directory と SSO するためのファイル等を指定します。

[次のステージ: ネットワーク]をクリックします。

仮想ネットワークを選択します。

仮想ネットワークの内容を確認しておきます。

[次のステージ: レビュー+作成]をクリックします。

作成内容を確認したら、上部にある[作成]をクリックします。

Kubernetes クラスターのセットアップが開始します。

Kubernetes クラスターのソフトウェアイメージをダウンロードしたりします。

当該環境では、24分ほどでセットアップしました。

[完了]をクリックします。

Kubernetes クラスターが出来上がっています。

Azure Arc にも情報が登録されていました。

Windows Admin Center で CSV のシンプロビジョニング オプションをみる

Azure Stack HCI でのストレージの仮想プロビジョニング

という新機能を聞いていましたが、Windows Admin Center の UI でそれをみました。
※オプションを確認したのは、Windows Admin Center 2110

CSV 作成後、プロビジョニングは、UI 上から変更できません。

現状、固定で作成した CSV は、シンプロビジョニング（仮想）に変換することはサポートされていないそうです。この点を含めた FAQ 的な内容は、Azure Stack HCI でのストレージの仮想プロビジョニング に記載があるので、ご一読をお勧めします。

稼働停止した Azure Stack HCI OS で Nested Hyper-V を組むので、Install-WindowsFeature -Vhd した

稼働停止した  Azure Stack HCI OS 21H2で Nested Hyper-V を組むので、Install-WindowsFeature -Vhd した。
※WAC のクラスター作成で Hyper-V の有効化を失敗したので、この方法を思い出して採用。

Install-WindowsFeature -Vhd D:\Hyper-V\g2ashcios01\127GB.vhdx -Name Hyper-V, FS-Data-Deduplication, FS-FileServer, BitLocker, RSAT-Feature-Tools-BitLocker, RSAT-ADDS-Tools, NetworkATC, Data-Center-Bridging, Failover-Clustering, RSAT-Clustering-PowerShell, Hyper-V-PowerShell

Install-WindowsFeature -Vhd E:\Hyper-V\g2ashcios02\127GB.vhdx -Name Hyper-V, FS-Data-Deduplication, FS-FileServer, BitLocker, RSAT-Feature-Tools-BitLocker, RSAT-ADDS-Tools, NetworkATC, Data-Center-Bridging, Failover-Clustering, RSAT-Clustering-PowerShell, Hyper-V-PowerShell

上記の通り、2台分実施しました。