Microsoft Tech Summit 2017本情報の内容(添付文書、リンク先などを含む)は、Microsoft Tech Summit 2017 開催日(2017 年 11 月 8日 - 9 日)時点のものであり、予告なく変更される場合があります。
{
“名前” : “真壁 徹(まかべ とおる)”,
“所属” : “日本マイクロソフト株式会社”,
“役割” : “クラウド ソリューションアーキテクト”,
“経歴” : “大和総研  HP Enterprise”,
“特技” : “クラウド & オープンソース”
}
レベル400のセッションです
Webですぐ見つかるような話はしません
Azure-Managed User/Partner-Managed
Azure-Managed User/Partner-Managed
このセッションの
カバー範囲
正直、マネージドサービスに任せたい
でも、中身は理解したい
その気持ち、わかります
コンテナー = Docker と考えてOK?
なにやら界隈が騒がしいけど
runC (OCI)
containerd (CNCF) CRI-O
CRI-containerd
Docker
Engine
Kubernetes & Tools
Docker Image Format
Orchestrators/Tools
(Docker Based)
Docker
Platform
Specific
Platform
Independent
Linux Control Groups
cgroups
Namespaces
Pid, net, ipc, mnt, uts
Layer Capabilities
Union Filesystems: AUFS,
btrfs, vfs, zfs*,DeviceMapper
Other OS
Functionality
Containerd + runC
Docker Engine
REST Interface
libcontainerd graphlibnetwork plugins
Windows Control Groups
Job objects
Namespaces
Object Namespace, Process
Table, Networking
Layer Capabilities
Registry, Union like
filesystem extensions
Other OS
Functionality
Compute Services
Docker Client Docker SwarmDocker Compose Docker Registry
App
Host User Mode
Container
Runtime
App App
Virtual Machine
App
Host User Mode
Container
Runtime
Hyper-V Isolation
Virtual Machine
Optimized for Container
App
https://docs.microsoft.com/ja-jp/virtualization/windowscontainers/deploy-containers/system-requirements
10.0.14393.206
App
Host User Mode
Container
Runtime
Hyper-V Isolation
Virtual Machine
Optimized for Container
App
Hyper-V Isolation
Virtual Machine
Optimized for Container
App
そろそろ話題のKubernetes(K8s)の
話ですかね!
おっと、その前に
Layer metadata (json)
Layer payload (tar)
Layer metadata (json)
Layer payload (tar)
Layer metadata (json)
Layer payload (tar)
 入れ替え、使い捨てやすい
コンテナーにする
 .dockerignoreファイルを使
う
 マルチステージビルドを活
用する
 余計なパッケージを入れな
い
• コンテナーにはひとつひと
つ違う役割を持たせる
(詰め込まない)
• イメージレイヤーを少なく
する
• 引数は改行&ソートする
• キャッシュを活かす
https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/
“Resource Central: Understanding and Predicting Workloads for Improved
Resource Management in Large Cloud Platforms” Microsoft, SOSP 2017
素敵ですが
ブラックボックスで気持ち悪いです
Container Group Namespace
Container A Container B
(Exposed) Port: 80 Port: 6000
• 同じコンテナーグループ
のコンテナーは、同じ仮
想マシンに配置
• コンテナーグループは代
表で1つの公開パブリック
IPとポートを持てる
• コンテナーグループ内で
はlocalhostとしてコンテ
ナー間通信が可能
• “サイドカー”
• コンテナーはAzure File
Storageをマウントできる
Container Group Namespace
sidecar
• 2つのコンテナー
• getenv: 各種環境情報
を取得し表示する
HTTPサーバー
• sidecar: getenvコンテ
ナーの監視
• せっかくなので軽量に
• コンテナーサイズは約
10MBytes
• Golang + Alpine Linux
• マルチステージビルド
getenv
(Exposed) Port: 8080
169.254.169.254
ピンとこないなぁ
典型的な使い方教えて
Azure Batch Pool
Spark
Master/Worker
Spark Worker
Data Store
https://github.com/Azure/batch-shipyard
コンテナーの群れを指揮するオーケストレーターが必要
たくさんオーケストレーターがあるけど
Azureで注目のサービスは?
(個人の意見です)
フロントエンド
Load balancer
Runtime
Database
API
Endpoint
永続
ストレージ
Local Container
Cache
Monitoring Service
SCM
Container
App
Container
アプリへの
リクエスト
SSH
Proxy
• Exposeしたポートは[ア
プリ設定] > [環境変数]
のWEBSITES_PORTで明
示的に指定できる
docker run -d -p 56785:8080
PORT="8080"
もうひとつの注目サービス
本日のメインイベント
楽なのでAKSを使いたいです
でも中身は理解しておきたいです
では見てみましょう
クラスター作成時に要求される
サービスプリンシパルが
ちょっと気持ち悪いです
LoadBalancer
UDR? User Defined Route?
ネットワーク構成が謎すぎて
夜も眠れない
Microsoft.ContainerService/managedClusters
API Version 2017-08-31
https://github.com/Azure/acs-
engine/blob/366ebc8ddd44388d637a6
56e2269cd0b0034703d/parts/kubernet
esmastercustomscript.sh
Container
Container
Container
Container
Container
Container
Container
Container
Container
Container
Container
Container
Prefix Next Hop
10.244.2.0/24 10.240.0.4
10.244.3.0/24 10.240.0.5
UDR
Flannelなどで
オーバーレイせ
ずにすむ理由
モデル 特徴 懸念
NAT NATの裏にコンテナーネットワークを
閉じ込める
K8sのコンテナー間通信では使えない
Transparent コンテナーをVMネットワークに露出さ
せる
接続スイッチの学習MACアドレスが多く
なる
Overlay ノード間でトンネルを掘り仮想的なプ
ライベートネットワークを作る
Overlayの仕組みを構築維持する必要があ
る (FlannelやWeaveなど)
L2 Bridge Transparentの進化系(MAC変換で露出す
るMACアドレスを少なく)
DHCPが使えない
L2 Tunnel 変換、転送、トンネリングをホストの
SDN機能(AzureではVFP)に任せる
ホストのSDN機能に依存
-A KUBE-SERVICES -d
10.0.134.197/32 -p tcp -m comment
--comment "default/azure-vote-
front: cluster IP" -m tcp --dport 80 -j
KUBE-SVC-GHSLGKVXVBRM4GZX
(中略)
-A KUBE-SEP-CYIUI5GK6PK6K23I -p
tcp -m comment --comment
"default/azure-vote-front:" -m tcp -j
DNAT --to-destination 10.244.2.5:80
Node
iptables
(Netfilter)
Client
kube-proxy
Container
(Pod)
Node
iptables
(Netfilter)
kube-proxy
Container
(Pod)
Master
10.0.134.197
10.244.2.5
Node
iptables
(Netfilter)
Client
kube-proxy
Container
(Pod)
Node
iptables
(Netfilter)
kube-proxy
Container
(Pod)
Master
10.244.0.4
10.244.2.5
-A KUBE-SERVICES -d
52.243.38.6/32 -p tcp -m comment -
-comment "default/azure-vote-front:
loadbalancer IP" -m tcp --dport 80 -j
KUBE-FW-GHSLGKVXVBRM4GZX
(中略)
-A KUBE-SEP-CYIUI5GK6PK6K23I -p
tcp -m comment --comment
"default/azure-vote-front:" -m tcp -j
DNAT --to-destination 10.244.2.5:80
Azure
LB
52.243.38.6
DSR
サービスの公開IP
Windows Container Host VM
vEthernet
(HNS Internal NIC)
172.20.224.1/20
vEthernet
(HNS Transparent)
10.240.0.4/8
10.244.1.1/25
vEthernet
(forwarder)
機能 Windows v1709以前 Windows v1709 Linux
ひとつのPodに
複数のコンテナー
×
(Podあたり1コンテナー)
〇 〇
Podの
エンドポイント統合
×
(2つのエンドポイント:
Transparent + NAT)
〇 〇
カーネルモードでの
負荷分散
× 〇 〇
CNIのサポート × 〇 〇
https://www.cncf.io/blog/2017/09/08/windows-
networking-parity-linux-kubernetes/
VM
VFP
Southbound API
GFT Offload API (NDIS)
VMSwitch
GFT
Table
First Packet
GFT Offload Engine
40/
50G
QoSCrypto RDMA
GFT
Transposition
Engine
REWRITE
SLB Decap SLB NAT VNET ACL Metering
ControllerControllerController
Encap
SmartNIC
(w/FPGA)
DNATDecap Allow Meter
Rule Action
* Meter
Rule Action
* Allow
Rule Action
* Rewrite
Rule Action
* DNAT
Rule Action
* Decap
Flow Action
1.2.3.1->1.3.4.1,
62362->80
Decap, DNAT,
Rewrite, Meter
Flow Action
1.2.3.1->1.3.4.1,
62362->80
Decap, DNAT,
Rewrite, Meter
Orchestrator
(K8s, DC/OS, Service Fabric)
3rd party
plugins
IPAM
Plugin
Operating System (Windows, Linux)
CNI
Container
Runtime Network
Plugin
Container1 Container2 Container3
テンプレートの中身をもっと知りたい!
新技術を試したい!
https://github.com/Azure/acs-engine
■
 https://github.com/ToruMakabe/TechSummit2017
[Japan Tech summit 2017] DEP 005

[Japan Tech summit 2017] DEP 005