「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
Azure の マネージド Kubernetes(k8s)
- Azure Kubernetes Service (AKS) は k8s のノードの利用に対してだけ課金を行う、Azure のサービス
- マスターノードや k8s のバージョン管理、必要なツール類の提供は全て Azure の機能と統合され Microsoft が管理する
詳細 †
朱書きはリスタート手順
AKS 追加のアーキテクチャ †
Kubernetesのアーキテクチャに追加されたアーキテクチャ。
ノードプール †
- Azure Virtual Machine Scale Sets (VMSS)
- ノードプール内のノードは
- ノードプールに所属する。
- 異なる VM で構成できる。
コンテナ・レジストリ †
AKSのコンテナ・レジストリは、Azure Container Registry (ACR)と言う。
ネットワーク関連の情報 †
認証・認可関連の情報 †
その他の情報 †
基盤保守 †
開発~デプロイ †
参考情報 †
チュートリアル †
前提 †
- Kubernetes CLI のインストール
>az aks install-cli
voting-appのエビデンス †
(1) アプリケーションを準備 †
- docker-compose でイメージを実行。
>docker-compose up -d
- 動作確認が完了したらコンテナを終了。
>docker-compose down
(2) コンテナ・レジストリを作成 †
コンテナ・レジストリ ≒ Azure Container Registry (ACR)
- コンテナ・レジストリ(ACR)にプッシュしたイメージを確認
- ImageName?
>az acr repository list --name daisukenishinoacr --output table
Result
----------------
azure-vote-front
- Tag
>az acr repository show-tags --name daisukenishinoacr --repository azure-vote-front --output table
Result
--------
v1
(3) Kubernetesクラスタを作成 †
- サービス・プリンシパルの作成
>az ad sp create-for-rbac --skip-assignment
{
"appId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"displayName": "azure-cli-2019-12-12-08-08-32",
"name": "http://azure-cli-2019-12-12-08-08-32",
"password": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"tenant": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}
- クラスタの作成
作成時、SSH キーがユーザーディレクトリの .ssh に作成される。
- appId : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
- password : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
>az aks create --resource-group daisukenishino --name daisukenishinoaks --node-count 2 --service-principal "<appId>" --client-secret "<password>" --generate-ssh-keys
SSH key files 'C:\Users\nishi\.ssh\id_rsa' and 'C:\Users\nishi\.ssh\id_rsa.pub' have been generated under ~/.ssh to allow SSH access to the VM.
If using machines without permanent storage like Azure Cloud Shell without an attached file share, back up your keys to a safe location
{...json...}
- バージョンの確認
(Serverも表示されるようになる)
>kubectl version
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.8", ...}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.12", ...}
- Azure ポータルから確認
ここまでやったら、Azure ポータルから
resource、resource-groupを確認してみてもイイ。
(4) アプリケーションを実行 †
- コンテナ・レジストリ(ACR)のログイン・サーバ名を取得(前述)
- azure-vote-all-in-one-redis.yamlの編集
イメージの出所をACRのログイン・サーバ名に変更する。
- デプロイ・マニフェストについて。
以下の4セクションで構成されている。
- (1) バックエンド(Redis)のデプロイメントの作成
- (2) バックエンド(Redis)に対するサービスの作成
- (3) フロントエンド・アプリのデプロイメントの作成
- (4) フロントエンド・アプリに対するサービスの作成
- K8sダッシュボードから確認(前述)
リソースの消費状況を確認できる。
(5-1) アプリケーションをスケール(pod) †
- ポッドを手動スケーリング
デプロイ・マニフェストに対してポッド数を明示的に指定。
- ポッドを自動スケーリング
閾値を用いて、自動でのスケールアウト
(5-2) アプリケーションをスケール(node) †
ポッドが増えた場合、ノードが不足するので、ノードを追加する必要がある。
- ノードの自動スケール
プレビューとしてノードの自動スケールもサポート
(5-3) ユーティリティによる負荷テスト †
- 実行
>kubectl run -i --tty load-generator --image=busybox /bin/sh
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
If you don't see a command prompt, try pressing enter.
/ # while true; do wget -q -O- http://xxx.xxx.xxx.xxx/; done
...ココで負荷テストが実行される。...
...終了するには「ctrl+c」を押下する。...
/ # exit
Session ended, resume using 'kubectl attach load-generator-xxxxxxxxxx-xxxxx -c load-generator -i -t' command when the pod is running
>kubectl attach load-generator-xxxxxxxxxx-xxxxx -c load-generator -i -t
If you don't see a command prompt, try pressing enter.
/ #
(6) アプリケーションを更新 †
- アプリケーションを更新する。
azure-vote 内の config_file.cfg のタイトル部分を変更
- Dockerコンテナを実行する。
>docker-compose up -d
- v1, v2のレプリカを確認できる。
>kubectl get replicasets -o wide -l app=azure-vote-front
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
azure-vote-front-xxxxxxxxxx 0 0 0 4h17m azure-vote-front daisukenishinoacr.azurecr.io/azure-vote-front:v1 app=azure-vote-front,pod-template-hash=xxxxxxxxxx
azure-vote-front-yyyyyyyyyy 3 3 3 23m azure-vote-front daisukenishinoacr.azurecr.io/azure-vote-front:v2 app=azure-vote-front,pod-template-hash=yyyyyyyyyy
(7) クラスタのアップグレードと削除 †
- アップグレード可能バージョンの確認
>az aks get-upgrades --resource-group daisukenishino --name daisukenishinoaks
{
"agentPoolProfiles": null,
"controlPlaneProfile": {
"kubernetesVersion": "1.13.12",
"name": null,
"osType": "Linux",
"upgrades": [
{
"isPreview": null,
"kubernetesVersion": "1.14.7"
},
{
"isPreview": null,
"kubernetesVersion": "1.14.8"
}
]
},
"id": "",
"name": "default",
"resourceGroup": "daisukenishino",
"type": "Microsoft.ContainerService/managedClusters/upgradeprofiles"
}
- アップグレードの実行
>az aks upgrade --resource-group daisukenishino --name daisukenishinoaks --kubernetes-version 1.14.7
Kubernetes may be unavailable during cluster upgrades.
Are you sure you want to perform this operation? (y/n): y
Since control-plane-only argument is not specified, this will upgrade the
control plane AND all nodepools to version 1.14.7. Continue? (y/N): y
{...json...}
- アップグレードの検証
>az aks get-upgrades --resource-group daisukenishino --name daisukenishinoaks
{
"agentPoolProfiles": null,
"controlPlaneProfile": {
"kubernetesVersion": "1.14.7",
"name": null,
"osType": "Linux",
"upgrades": [
{
"isPreview": null,
"kubernetesVersion": "1.14.8"
},
{
"isPreview": true,
"kubernetesVersion": "1.15.4"
},
{
"isPreview": true,
"kubernetesVersion": "1.15.5"
}
]
},
"id": "",
"name": "default",
"resourceGroup": "daisukenishino",
"type": "Microsoft.ContainerService/managedClusters/upgradeprofiles"
}
- ここには、nodesをホストする vm が含まれるらしい。
- 依存関係があるらしく、az group deleteすると一緒に消える。
SQL Serverのエビデンス †
(0) 前提 †
(1) ストレージの準備 †
先ずは、ストレージとして、永続ボリュームを作成する。
(非永続ボリュームの確認は、Qiitaの記事の手順を確認するだけに留める)
- kind: StorageClass?
前半はストレージ・クラス用
- metadata: name: azure-disk
名前は azure-disk
- parameter:
渡すパラメタを指定。
・kind: Managed
管理ディスク
・storageaccounttype: Premium_LRS
ストレージのsku
- その他
・ReclaimPolicy? の設定がないため、既定の Delete が適用
- kind: PersistentVolumeClaim?
後半は永続ボリューム要求用
- metadata:
・name: mssql-data
名前は mssql-data
・annotations: volume.beta.kubernetes.io/storage-class: azure-disk
ストレージクラスとして Azureのディスク ストレージ を指定
- spec:
・accessModes: - ReadWriteOnce?
ボリュームに対するアクセス(1 つのポッドのみがアクセス)
・resources: requests: storage: 8Gi
容量を指定
- Azure ポータルから確認
MC_から始まる、ResourceGroup?の中に、
「kubernetes-dynamic-pvc-...」のディスクを確認できる。
(2-1) SQL のインストール †
シークレットの作成や SQL Server 2017 の配置
- containers.env:
コンテナに渡す各種引数を指定
- name: MSSQL_PID
value: "Developer"(SQL Server Developer Edition)
- name: ACCEPT_EULA
value: "Y"
- name: MSSQL_SA_PASSWORD
作成したシークレットは valueFrom.secretKeyRef? で取得
- containers.volumeMounts:
ボリュームを「/var/opt/mssql」にマウント
- spec.volumes:
前回作成した永続ボリューム要求を指定
(2-2) SQL の障害復旧の検証 †
- mssqlにアクセスしてみる。
- Azure Data Studioで接続&ログインする。
- Connection Type : Microsoft SQL Server
- Server : <External IP Address>
- Authentication : SQL Login
- Account
- UID : SA
- PWD : xxxxxxx
- DDL、DML(INSERT)実行
得意の「instnwnd.sql」を使用して「SELECT * FROM SHIPPERS」でも実行する。
(exec sp_dboptionの部分は旧ver向けstatementなのでコメントアウトするか削除する)
- ポッド再配置を行う。
(これは、アプリではなくDBインスタンスの再起動になる。)
- 再配置後、mssqlにアクセスできることを確認する。
- 接続&ログインし、
- DML(SELECT)を実行する。
- 再配置後、mssqlにアクセスできることを確認する。
- 接続&ログインし、
- DML(SELECT)を実行する。
- Azure ポータルから確認
ディスクが新しいノードにアタッチされていることを確認できる。
(「所有者 VM」の欄に、変更後のNODEのIDが表示される。)
ASP.NET Coreのエビデンス †
(0) 前提 †
- Visual Studio 2019 または dotnet core 3.0 が利用できる環境
(1) 事前準備 †
- 差異
- 2つのデプロイ・マニフェスト(StorageとRDBMS)が結合され、
- DBのシークレット作成処理が含まれる。
("MyC0m9l&xP@ssw0rd"をBase64化した値を指定している)
- Azure Data Studioでデータを追加(前述)
- IPアドレス:SQL Serverのサービス名("mssql-deployment")に変更
- パスワード:作成したシークレット("MyC0m9l&xP@ssw0rd")に変更
- 最後の「type: LoadBalancer?」削除して再適用
(2) アプリを開発 †
- チュートリアルのサンプルが微妙なのでコチラを使用する。
- voting-appと同様にRedisを使用する。
(チュートリアルでは、Redisを使用していない)
- DBMSは、SQL Serverを使用する。
(チュートリアルでは、K8s上のDBを直参照するが、)
(3-1) アプリをデプロイ(ACRへ) †
- SQL Server
- IPアドレス:SQL Serverのサービス名("mssql-deployment")に変更
- パスワード:作成したシークレット("MyC0m9l&xP@ssw0rd")に変更
- コンテナ・レジストリへアップロード
- dotnet coreのみ、コンテナ・レジストリへアップロード
- Visual Studioの発行でも出来るようなのでこちらを使用。
- Visual Studioで発行(コンテナ・レジストリへアップロード)手順
- プロジェクトを右クリックし発行を選択する。
- 「既存のACR」を選択して、以下のダイアログから発行をする。
- リモート
ImageName?
>az acr repository list --name daisukenishinoacr --output table
Result
---------------
webapplication1
Tag
>az acr repository show-tags --name daisukenishinoacr --repository webapplication1 --output table
Result
--------
latest
- タグを設定する。
直ぐに発行しないで、プロファイル作成を
選択すると初回からこちらを選択可能。
- リモート
ImageName?
>az acr repository list --name daisukenishinoacr --output table
Result
---------------
webapplication1
Tag
>az acr repository show-tags --name daisukenishinoacr --repository webapplication1 --output table
Result
--------
yyyymmddhhmmss
(3-2) アプリをデプロイ(K8sへ) †
- 以下の様に、webapplication1.yamlを作成する。
- webapplication1.yamlの<Tag>を更新し、
(4) アプリの構成 †
- イングレス コントローラー(AKS独自)の構成
EXTERNAL-IPをFQDNに変更できる。
- webapplication1.yamlの編集
- サービスのタイプを変更(LoadBalancer?を削除)し、
- イングレス コントローラーを追加
- webapplication1のEXTERNAL-IPが<none>に変更されたことを確認。
>kubectl get svc
- FQDN名の確認。
>kubectl get ingress
- Azureポータルから DNS ゾーンにAレコードが追加されたことを確認できる。
- Viewで、@Environment.MachineName? を使用して実行中のポッド名を表示
- webapplication1.yamlの編集
webapplication1のDeploymentを変更する。
- ブラウザよりアプリにアクセス。
F5 で更新してポッド名が変わることを確認。
(5) 複数ノードプールの構成 †
おいおいヤる予
(6) ネットワークの構成 †
おいおいヤる予
(7) Gatewayの構成 †
おいおいヤる予
(8) ラベル、セレクターと名前空間 †
おいおいヤる予
(9) 自動スケール †
おいおいヤる予
その他のコンテンツ †
参考 †
Microsoft Docs †
チュートリアル †
- Kubernetes on Azure のチュートリアル
- SQL Server on Linux のチュートリアル
サポート ポリシー †
Qiita(ASK を使いこなす) †
AKS チュートリアルの深堀 †
上記のMicrosoft Docsのチュートリアルの深堀しているQiita記事(MS社員)。
SQL Server 2017 を AKS で使う †
AKS で asp.net core アプリケーション †
Azure | SIOS Tech. Lab †
https://tech-lab.sios.jp/archives/category/azure/
NGINX †
- Azure Kubernetes ServiceでNGINX
共有ストレージ †
- Azure Kubernetes Serviceでの共有ストレージ
kubectl †
OSSコンソーシアム †
Blog †
- Docker for Windows上で Docker Composeでテストし、Open PaaSにデプロイできる
Wiki †
- マイクロソフト系技術情報 Wiki(当該Wiki)
Tags: :クラウド, :コンテナ, :Azure, :AKS, :IaC