マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

K8sのポイント

採用

  • K8sは難しい。
  • 以下の目的にて異合しているか?
  • 可搬性
    • K8s採用の目的は主に可搬性
    • ただ、可搬性の大部分はコンテナで担保
  • マイクロサービス
    • アーキテクチャを構成し易い。
    • Ingress - Service - Pod構成

基本構成

  • 制御プレーン
    • Master APIを持っている
    • Kubernetes CLI(kubectl)から操作する。
    • AKSでの変更点はコチラ
  • 実行ノード
    • VMSS : VM Scale Set
    • Ingress - Service - Pod構成
      ※ Ingress - Serviceの詳細はコチラ
  • Pod
    ・Dockerコンテナ
    ・1podに複数コンテナを配置可能
  • Service
    ・L4ロードバランサ
    ・サービス・メッシュを構成
  • Ingress
    ・L7ロードバランサ
    ・必須ではない(オプショナル)

デプロイ方式

  • Deploymentでラッピングされている。
  • Podを物理ノードに配置する方式
  • ReplicaSet方式
    通常は、空いている物理ノードに均等に割り当てる。
  • DemonSet方式
    すべての、または特定の物理ノードに1つだけ配置する

名前空間

  • *.yamlで名前空間を定義すると、
  • Kubernetes CLI(kubectl)から指定が必要になる。
  • 下位には、ServiceDeploymentがある。

kube configファイル

  • これは、Master APIにアクセスするためのクレデンシャル情報。
  • AKSでは「az aks get-credentials」によって取得する。
    「--admin」オプションを付与
    • した場合、AKSクラスタ 管理者権限のクレデンシャルを取得
    • しない場合、AKSクラスタ ユーザ権限のクレデンシャルを取得

※ K8sの権限については、コチラを参照。

※ 「--admin」オプションを付与するには、Azure RBACロールの要件がある。

  • kube configファイルの一般的な話はコチラ

ダッシュボード

ダッシュボードを追加して利用可能

AKSのポイント

AKS : Azure Kubernetes Service

制御プレーン

  • 構築不要 ≒ マネージド
  • az コマンドで構築可能
  • 1つのリソース・グループとしてまとめて作成される。
  • ノードプールの機能が拡張されている。

実行ノード

  • 構築不要 ≒ マネージド
  • az コマンドで構築可能
  • 1つのリソース・グループとしてまとめて作成される。
  • ノードプールから実行ノードが割り当てられる。

ACR

  • ACR : Azure Container Registry
  • ユーザの作成したプライベートなコンテナを登録する。
  • コンテナの置き場所(他のXKE / XKSにもコンテナ・レジストリはある)

MCR

  • MCR : Microsoft Container Registry
  • AKSの基本動作に必要な実行ノード用のコンテナを登録する。
  • コンテナの置き場所(他のXKE / XKSにもコンテナ・レジストリはある)

詳細

AKS概要

内容

kubectlによる状態確認

  • 一覧取得
    kubectl get <リソース種別> --namespace <名前空間>
  • 詳細取得
    kubectl describe <リソース種別> <ID> --namespace <名前空間>
  • 対象削除
    kubectl delete <リソース種別> <ID> --namespace <名前空間>

ダッシュボードによる状態確認

  • 以下のコマンドを使用する。
    • cluster-admin ロールに対して k8s ダッシュボードへのアクセス権限を
      • 付与
        kubectl create clusterrolebinding kubernetes-dashboard -n kube-system --clusterrole=cluster-admin --serviceaccount=kube-system:kubernetes-dashboard
      • (削除)
        kubectl delete clusterrolebinding kubernetes-dashboard -n kube-system
  • ダッシュボードを開く。
    az aks browse --name $AKS_CLUSTER_NAME --resource-group $RG_AKS
  • ココのチュートリアルでは、名前空間を使用しているので、
    ダッシュボード左のペインから名前空間を選択して利用する。
  • プロキシを停止するときは以下を行う。
    • シェルを使用している場合、CTRL+Cを実行して停止する。
    • Azure Cloud Shellのウィンドウを閉じてしまった場合など、
      ps -efl | grep 8001
      kill <pid>

基本的トラブルシュート

  • Service が起動しない
    • External IP (Public IP) が適切に付与できているかを確認
      kubectl get services --namespace <名前空間>
    • サービスの作成が正しく行えたかどうかのログを確認
      kubectl describe services <サービス名> --namespace <名前空間>
  • Pod が正しく動作しているかを確認したい
  • Pod のログを確認
    kubectl logs <Pod名> --namespace nmssample
  • Pod 上でコマンドを実行
    kubectl exec <Pod名> --namespace nmssample ls
  • ポート・フォワードしてPod内部動作を確認
    例) localhost:8000 → コンテナ上の ポート 80
    kubectl port-forward <Pod名> --namespace nmssample 8000:80
  • Pod が正しく動作しているのに Service の L4LB 経由でアプリが呼び出せない
    • YAML ファイルの selector の記述が正しいかを確認
      ※ selector は記述が間違っていてもエラーを出さない

ツールやライブラリ

  • Helmパッケージマネージャ
    • Pod, Service, Ingress などの構成を一括で行うことができるパッケージマネージャ
    • K8sリソースのインストール / アンインストールを容易化できるのがメリット
  • nginx
    • OSS の軽量 Web サーバで、リバースプロキシとしてよく利用される
    • K8sでは、簡易な Ingress として利用されることが多い
  • Istio サービス・メッシュ
    • マイクロサービスの共通処理を担うサービス・メッシュの定番
    • 業務用のコンテナ + Istio のコンテナで各 Pod を構成して展開する形で利用
  • Prometheus
    • K8s監視ツールの定番
    • 他の監視ツール(クラスタ基盤の監視ツール)と
      組み合わせて利用されることが多い
  • Grafana
    • グラフィカルなダッシュボードの表示ツールの定番
    • Prometheus などと組み合わせて利用される

構成のポイント

≒プライベート化のポイント

(動画も3時間半と長く、内容も濃いので、
Azure側も理解しながらだと、一気通貫に1週間位かかる)

物理インフラ構成

  • 実際の物理インフラは、

に分かれる。

  • フルコンテナ化
    現時点では難しい。
  • 特に、DBサーバが難しい
  • 監視サーバは基盤外が良いケースが多い。
  • Kubernetes CLI(kubectl)か、Azure CLIか。
  • Kubernetes CLI(kubectl)
    • Ingress - Service - Pod構成
    • ダッシュボード
  • Azure CLI
    • コンテナ・レジストリ
    • マネージド・サービス(PaaS)版のDB
    • その他
      ・監視サーバ
      ・機密情報保管庫(Key Vault)

ネットワーク構成

  • ネットワーク分離
  • CNI方式
    ≒PodのIPアドレスの付与の方式
  • kubenet方式
    仮想IPを使用して、NAT変換する。
  • Azure CNI方式(推奨
    PodのIPにVNETのIPが使用されるが、
    Azureの仮想ノードやサービスを利用可能。
  • 内部設置
  • VDC内部に配置
    大量のプライベートIPアドレスを使用してしまう。
  • VNET分離(推奨
    Azure Private Linkでオンプレ接続する。
    ・すると、プライベートIPアドレスを消費しない。
    ・また、テスト面の構築などの場合にも便利。
    VNETからオンプレに入れないのでセキュア
  • Master APIのプライベート化
  • しかし、
    ノードプールVNET内に配置するという話ではない。
     (ただし、デモでは既存のVNETに配置している)
    ・また、ARM APIがパブリックなので、
     Master APIだけプライベートではアンバランス。
  • 既存のアクセス制限機能を使用(推奨
  • 入力経路の制限 (Ingress Lockdown)
    制御プレーンからノードプール
     不要(出力方向で通信するため)
    ・保守端末からノードプール
     ・インターネット:Azure Bastion
     ・オンプレ:Azure Private Link
    ・エンドユーザーからアプリケーション
     コチラは長くなるので、コチラを参照。
  • Service CIDR、Docker Bridge CIDR
    • Service CIDR
    • Docker Bridge CIDR

認証・認可

  • インフラ
    • Azure Portal, Azure CLI (ARM API)の認証・認可
      • 既定で、AzADの認証を要する。
      • 追加で、前述の、
        ・AzADによる条件付きアクセス機能を構成する。
        ・若しくは、IPアドレス制限 / プライベート化を構成する。
  • 中間(境界線が引き難い)
    • K8sダッシュボード, Kubernetes CLI(kubectl)
      • az aks get-credentials」でkube configファイルを取得
      • 必要に応じて、以下の持ち出し対策を行う。
        AzAD認証と統合する。→ コチラ
        前述のMaster APIのIPアドレス制限 / プライベート化
        ※ IPアドレス制限 / プライベート化で十分という説もある。

基盤保守

  • K8sのバージョンアップは手動
    (AKSとK8sのバージョンの関係が重要)
  • ノードの更新
    • 実行ノード(Linuxノード、Windowsノード)に対して行う。
    • OSのセキュリティ・アップデート(Ubuntu)は日次で自動更新される。
    • Kuredと言うOSSをK8sにインストールすると、再起動をしてくれる。
    • ノードプール(VMSS)のローリング・アップデート機能はAKSでは非サポート。
  • Podの更新
    • コンテナ・レジストリ内のイメージ
    • イメージ内のアプリ
      • アプリ自体
      • ライブラリ

※ 詳細はコチラ

開発~デプロイ

  • 一般的な DevOps ワークフロー
  • 金融系等では「PoC → 開発 → 本番」環境分離(セキュリティ境界)を考慮

※ 詳細はコチラ

構築デモ

参考

資料

YouTube?で限定公開とあるケド、Facebookで公開なのって、実質「公開」って事で良いんだよね?

Microsoft Docs

ベスト プラクティス


Tags: :クラウド, :コンテナ, :Azure, :AKS, :セキュリティ, :通信技術, :セキュリティ, :認証基盤


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2020-05-14 (木) 10:28:35 (19d)