Azure Arc・ハイブリッド

Azure Hybrid Day の技術要素を整理する — Azure Arc / Azure Stack HCI を中心に この記事の内容 インフラの基本構成（CPU・ストレージ・ネットワーク）から、オンプレミス／プライベートクラウド／パブリッククラウドの配置モデルまでを俯瞰します プライベートクラウドの3種類（エンタープライズ・ローカル・ホステッド）の違いを整理します ハイブリッドクラウド・マルチクラウド環境が抱える「サイロ化」の課題と、Azure Arc による統合管理の考え方を解説します Azure Arc が管理できる対象範囲（OS・Kubernetes・SQL・VMware 等）を具体的に説明します アプリケーション開発者視点での Azure Arc の価値と、Azure Stack HCI の位置づけについても触れます はじめに Microsoft のハイブリッドクラウド関連技術は、Azure Arc、Azure Stack HCI、ハイブリッドクラウド、マルチクラウドなど、扱う要素が非常に多岐にわたります。それぞれの技術がどこに位置づけられるのか、互いにどういう関係にあるのかが見えにくくなりがちです。 本記事では、インフラの基礎からクラウドの配置モデル、そして Azure Arc が目指す世界観まで、全体を俯瞰しながら整理していきます。 インフラの基本構成から始める まず、どんな IT 基盤にも共通する「インフラの基本」を確認しておきましょう。 インフラとは突き詰めると、以下の3要素から成り立っています。 CPU・メモリ（計算リソース） ストレージ（データ保存） ネットワーク（通信） この3要素は、オンプレミスであってもクラウドであっても、物理サーバーであってもサービスとして利用する形態であっても変わりません。 その上に OS があり、ミドルウェアがあり、アプリケーションが乗ってきます。これは IT 基盤の基本中の基本です。 仮想化とコンテナ 現在では、物理サーバーに直接 OS を入れるケースよりも、ハイパーバイザーを介して**仮想マシン（VM）**を動かす形態がほぼ標準となっています。1台の物理サーバー上で複数の独立した環境を実現できるのが仮想化の大きなメリットです。 さらに近年ではコンテナという形態も広く普及しています。コンテナは OS を共有しつつ、各アプリケーションを独立した環境で動かす仕組みです。仮想マシンと比較すると軽量で、起動が速く、持ち運びやすいという特徴があります。 インフラの形態を大きく分けると、以下の3種類になります。 物理ハードウェアを直接利用する形態 仮想マシンを利用する形態 コンテナを利用する形態 どの形態であっても、その上にソリューションやアプリケーションが乗ってくるという構造は変わりません。 配置モデル — どこに置くか インフラをどこに配置するかという観点では、大きく2つの場所があります。 オンプレミス：自分たちが管理する場所に置く クラウド：クラウド事業者のインフラを利用する さらにクラウドは、プライベートクラウドとパブリッククラウドに分かれます。 ...

Azure Arc 対応 Kubernetes でのファイアウォール越えクラスター接続 この記事の内容 ファイアウォールの内側にある Kubernetes クラスターに、インターネット越しで外部から接続する方法を紹介します Azure Arc の Connected Cluster 機能を使い、グローバル側から穴あけなしで接続を実現します az connectedk8s proxy コマンドによるローカルプロキシ経由の接続手順を解説します Azure Active Directory ユーザー認証を用いた ClusterRoleBinding の設定方法を説明します ハイブリッドクラウド・エッジ環境への応用可能性についても触れます Azure Arc とファイアウォール越え接続の概要 通常、ファイアウォールの内側にある Kubernetes クラスターには、外部のパブリッククラウドや一般のインターネットからアクセスすることができません。ファイアウォールに穴を開ける（インバウンド許可ルールを追加する）必要があるため、セキュリティリスクが生じます。 Azure Arc の Connected Cluster 機能を使うと、クラスター側からのアウトバウンド接続のみを利用して、外部からクラスターへのアクセスを実現できます。つまり、ファイアウォールのインバウンドルールを一切変更することなく、世界中どこからでもそのクラスターに接続できるようになります。 検証環境 この検証では、以下の環境を使用しています。 ベースマシン: SE3号機（お借りしている環境） Hyper-V 上に Azure Local（旧 Azure Stack HCI）の OS を構築 その上に AKS（Azure Kubernetes Service）を導入 AKS のサービス上で Kubernetes クラスター（ワークロードクラスター）を1つ作成済み クラスターの kubeconfig ファイルは事前にダウンロードし、~/.kube/config に配置してあります。サーバーは 192.168.1.211 というプライベート IP アドレスで、ファイアウォールの設定は変更していない状態です。 ファイアウォール内のネットワークから直接 kubectl を実行すると、プライベート IP で疎通できるため問題なく動作します。 ...