这是目录。

1. 目的：为了操控AKS，需要考虑到相关资源的动向。

 

1. 前提：在操作AKS之前，需要了解构成AKS的Azure资源。

 

1. AKS操作中资源的变化：在操作AKS过程中，与之相关的资源会有所调整。

 

1. Azure资源构成AKS：构成AKS的是Azure平台上的各类资源。

 

总结：总而言之。

1. 目标

这篇文章是2018年Microsoft Azure Tech Advent Calendar的第22天的文章。

2018年是Azure Kubernetes Service（AKS）1、Amazon Elastic Container Service for Kubernetes（Amazon EKS）2等开始正式提供，并且Kubernetes在IBM收购RedHat方面扮演关键角色的一年，许多公司都加大了对Kubernetes的探索和投入。我相信在阅读本文的读者中，很多人都曾经尝试过使用kubectl命令。

这篇文章是从Azure的角度探讨Azure Kubernetes Service（AKS）作为Kubernetes平台之一的构成，介绍了AKS与Azure资源的关系。如果您目前正在使用Azure基础架构，并且想尝试使用AKS，但不知道Virtual Network、Virtual Machine等与之相关的内容，或者正在使用Kubernetes，并且想知道在使用AKS时需要注意些什么，希望对您有所帮助。

2. 前提 (Qiantí)

• Kubernetesの基礎知識(Podとは？Nodeとは？)にはこの記事では触れません。ただし、できる限り参考URLを載せるようにしているので、そこから基礎知識は参照できるようにしたいと思います。

 

AKSのネットワークはkubenetを用いた”基本”ネットワークとAzure CNIを用いた”高度”ネットワークがある4のですが、ここでは”高度”ネットワークを前提に紹介します。

3. 操作AKS时资源的运动。

我将介绍以下六个内容。关于每个资源的详细介绍将在下一章中给出。

• AKSクラスタを作成する

 

• PodがStorage Firewallを有効にしたAzure Fileをマウントする

 

• PodがAzure Container Registry(ACR)からimageをpullする

 

• クライアント(PCなど)がPodにアクセスする

 

• クライアント(PCなど)がKubernetesのAPIを呼ぶ

 

永続化ボリュームを作成する

创建AKS集群

Pod启用了Storage Firewall，并挂载了Azure文件。

Pod从Azure容器注册表（ACR）拉取镜像。

客户端（如电脑）访问Pod。

客户端（如PC）调用Kubernetes的API

创建持久化卷。

这个总结到这里

在Azure上运行AKS时，使用服务主体来操作Azure资源。从Kubernetes的角度来看，这符合云控制器管理器的概念。服务主体是理解AKS的重要组成部分。
此外，还存在一些类似于Azure虚拟机的操作，如挂载Azure Files和从客户端发送流量到Pod等。如果Azure IaaS工程师使用AKS，他们可以通过确定哪些方面是相同的和不同的来更容易理解。

组成AKS的Azure资源

构成资源 1 服务主体

要理解服务主体，可以尝试使用上述确认过的服务主体进行登录。您可以使用以下命令进行登录。

# az login --service-principal --username "サービスプリンシパルID" --password "サービスプリンシパルPassword" --tenant "テナント名"

可以使用以下命令来确认服务主体被分配了哪些权限。

# az role assignment list --assignee "サービスプリンシパルID" --all

构成资源2主节点

您可以通过以下命令获取认证信息。

# az aks get-credentials -g "リソースグループ名" -n "AKS名"

构成资源3网络

• Virtual Network: アドレス空間内にPodがプライベートIPアドレスを持ちます。他のVirtual Networkと接続したりVPN Gatewayを配置してオンプレミスなどとVPN接続することも可能です6。

 

• NSG(Network Security Group): Virtual Network外との通信においてアクセス制御を行います。なお、KubernetesのNetwork Policy(Podのマイクロセグメンテーション)はNSGでの制御でなくKubernetesでの設定として行います7。

 

• Load Balancer: Kubernetesのリソースである’Service’が追加された際はAzureではLoad Balancerのルールが更新されます。Public IPアドレスが追加となった際もLoad BalancerのIP構成として追加されます。

 

• Application Gateway: WAFなどをKubernetesが用いたい際に利用が可能です。また、Kubernetesのリソースである’Ingress Controller’としても利用できます8。

 

Azure DNS: AKSのアドオンである’HTTP アプリケーション ルーティング’を利用することで活用できます。このアドオンを用いると、Kubernetesで作成したIngressに対し外部から解決できる名前をAzure DNSに登録できます9。

负载均衡器的规则更新等操作是通过使用服务主体来执行的。

四個虛擬機的資源組成

Kubernetes的Agent Node是一个虚拟机，Pod在狭义上指的是虚拟机上的Docker容器。例如，通过SSH连接Agent Node虚拟机，可以观察到Docker容器正在运行等情况。AKS旨在提供托管的Kubernetes平台，因此会自动对Agent Node进行补丁安装。但需要注意的是，重新启动仍然需要用户自行操作。

资源组成：容器注册表5

尽管在流程中已经提到过，但是要使用容器注册表，需要使用服务主体进行身份验证。然而，在创建AKS时，并不会自动创建Azure容器注册表（ACR），因此用户需要自行授予服务主体对ACR的操作权限。这是使用AKS初次遇到的常见问题。官方文档中也有相关说明，请务必注意。另外，ACR是Kubernetes管理中的重要组件，每天都在不断开发新功能，并收到了许多反馈。

构成资源6 存储

在AKS中，常用作为存储的是Managed Disk和Azure Files。由于Managed Disk只能连接到单个虚拟机，因此在需要与单个Agent节点进行连接时使用，而Azure Files则在需要多个连接时使用。当需要进行备份时，目前似乎推荐使用Ark（第15章）。

构成资源7 – 其他

我认为这不是基本的构成要素，所以在本文中不放重点，但我认为其他资源是AKS的差异化因素。希望大家能够关注。我将简要介绍一下。

• Azure Container Instance(ACI): 単体ではdockerコンテナを稼働するAzureリソースに過ぎないのですが、Virtual Kubeletと組み合わせることでAKSのVirtual Nodeとして利用できます16。構想としては、Agent Nodeをユーザが意識せず、欲しい時に必要なリソースのPodを秒課金で利用できる世界を目指しているようです17。

 

• Azure DevOps: Visual Studio Team Service(VSTS)からリブランディングされました。これを用いることでAKSをCI/CDパイプラインへ容易に組み込めます18。

 

Azure Monitor for Container: Kubernetesを運用することを考えるとリソースや状態、ログの監視は不可欠です。AKSではAzureの監視サービスであるAzure Monitorとシームレスに統合しました19。2018年のアドベントカレンダーでも一般提供開始についての記事が投稿されています20。

个人观点是，我认为由于Kubernetes是一个开源平台，所以基本上无论在哪个云平台使用，都可以说是Kubernetes。这有点像极端情况下，无论在哪个云平台使用Linux虚拟机，都可以说是Linux一样。然而，正是由于上述功能的存在，才会出现不同云平台之间的差异，这也是很有趣的。此外，作为将ACI和AKS连接起来的Virtual Kubelet也是一个开源项目，并且成为CNCF的沙盒项目，这也是很有趣的。

总结

我已经试图介绍了与AKS相关的Azure资源是如何与AKS相关的。当在云平台上使用Kubernetes时，除了了解Kubernetes本身外，还需要了解各个云平台的特性等。希望通过这篇文章，您能对AKS有一些了解和喜欢。
如果有任何疑问或关注，请务必在评论栏中留言。

注脚