2021年12月18日土曜日

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

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


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

2021年12月10日金曜日

サービス アカウント ベアラー トークン/サービス アカウント トークン認証 で 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から文字列を引っこ抜きまして、下記画面に貼り付けます。

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

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





2021年12月9日木曜日

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

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

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

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

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

2021年12月7日火曜日

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

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

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

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

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

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

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


2021年12月2日木曜日

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 クラスターは、削除された模様。。。

2021年12月1日水曜日

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

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

法定停電が完了後は、
にしたがってというか、クラスターが起動すると 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