1.
Kubernetesを使う上で
抑えておくべきAWSの基礎概念
初心者向け Kubernetes on AWSやる上で覚えておこう
1
@mosuke5
(2019/6/24)

2.
Who are you?
2
名前: もーすけ (@mosuke5)
仕事:
DevOps系とかやってる人。
元Alibaba Cloud日本リージョンの中の人。
元システム開発系エンジニア。
ところで:
「お前、元Alibaba Cloudの中の人だろ？AWS知ってんのか？」
AWS Solution Architect Professionalも持ってます！競合(大先輩)調査です。
人気記事：サンプル問題集付き！AWSソリューションアーキテクトプロフェッショナル勉強方法
※Twitterアイコンは
一時的に別のものになっています。

3.
Agenda
3
1. 対象者と目的
2. 主な登場サービス
3. AWSのインフラストラクチャと基本思想（リージョンとAZ）
4. Service/Ingressとロードバランサー
5. PV/PVCとEBS
6. なぜKubernetesはAWSリソースを操作できるのか
7. FAQ

4.
対象者と目的
4
対象者
● これからKubernetesをAWS上で構築しようとしている人
● Kubernetesを少し勉強したが、AWSなどクラウドの経験が少なく、クラウド特
有の考え方について理解したい人
目的
Kubernetesを構築・利用する上で、最低限抑えておくべきAWSの基本的な考え
方やサービスについての理解の助けとすること。
Kubernetesの詳しい概念を説明やAWSのすべてのサービスを網羅するための
ものではない。

5.
主な登場サービス
5
EC2 Elastic Compute
Cloud
いわゆる一般的な仮想サーバのサービス。様々なインスタンスタイプをもちあらゆる
ワークロードに対応できるのが特徴。 KubernetesではMaster NodeやWorker Node
などサーバが必要な場面で必ず利用される基本サービス。
VPC Virtual Private Cloud クラウド上に、ユーザが定義したプライベートなネットワーク空間を作成することので
きるサービス。このVPC内部にEC2やELBなどのリソースを配置していくことになる。
その他、トラフィックのルーティング設定なども可能。
ELB Elastic Load
Balancer
ロードバランササービス。 Kubernetesでは外部からPodやAPIへアクセスするための
経路として用いられることが多い。 ELBの中にもCLB, ALB, NLBの3種類のタイプを
もつ。
EBS Elastic Block
Storage
EC2にアタッチ、マウントすることのできるブロックストレージサービス。 Kubernetes
では主にPersistent Volume(PV)として利用される。
IAM Identity and Access
Management
AWS全体のアカウント、権限管理を担うサービス。 AWSコンソールにアクセスするた
めのユーザ発行や、 API Key発行、実行できるアクションの制限・管理などができ
る。
Auto Scaling - 名前の通り負荷などに応じて EC2をスケールアウト・インさせるためのサービス。単
にスケールのためだけでなく、期待した数のインスタンスが可動しているか管理する
用途としても利用される。

6.
AWS超基礎概念（抜粋）
6

7.
リージョンとAZ
7
<リージョン一覧 (2019/6/17現在)>
us-east-1 米国東部（バージニア北部）
us-east-2 米国東部 (オハイオ)
us-west-1 米国西部 (北カリフォルニア)
us-west-2 米国西部 (オレゴン)
ca-central-1 カナダ (中部)
eu-central-1 欧州 (フランクフルト)
eu-west-1 欧州 (アイルランド)
eu-west-2 欧州 (ロンドン)
eu-west-3 EU (パリ)
eu-north-1 欧州 (ストックホルム)
ap-east-1 アジアパシフィック (香港)
ap-northeast-1 アジアパシフィック (東京)
ap-northeast-2 アジアパシフィック (ソウル)
ap-northeast-3 アジアパシフィック (大阪: ローカル)
ap-southeast-1 アジアパシフィック (シンガポール)
ap-southeast-2 アジアパシフィック (シドニー)
ap-south-1 アジアパシフィック (ムンバイ)
sa-east-1 南米 (サンパウロ)
※中国リージョンは別アカウント
リージョンは国や都市のレベルで、他のリージョンとは完
全に分離されたもの。世界で20くらい。
出典: https://aws.amazon.com/jp/about-aws/global-infrastructure/

8.
リージョンとAZ
8
リージョンの中に複数のAZ（Availability
Zone）がある。地理的に離れていて、送
電元が異なる、など災害に強くするため
に存在。
AZ間はプライベートなネットワークで接続
できる。
ちなみにAZは複数のデータセンタの集合
体を指す。
ユーザ自身がEC2などのインスタンスを
立てる際にどのAZに立てるか選択する。
お客様で考慮するべきポイント。
出典: https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-regions-availability-zones.html

9.
Multi-AZの基本構成
9
Multi-AZを用いた基本構成。
1. アプリケーションのフロントは
ELB(ロードバランサ)を利用して、
Multi-AZで配置。
2. アプリケーションが可動するEC2は
両方のAZに配置。
3. データベースはAmazon RDSを利
用して、Multi-AZで配備。
片方のAZが仮にダウンしてもアプリ
ケーションが可動し続けることが可能。
出典: https://aws.amazon.com/jp/cdp/cdp-dr/

10.
VPCネットワークの基礎
10
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-nat-gateway.html
VPC
Availability Zone 1 Availability Zone 2
Public subnet
Private subnet
Public subnet
Private subnet
Internet gateway
(igw)
Router
NAT gatewayInstance
Instance Instance
AWSの教科書的VPC設計は、各AZに
PublicとPrivateのサブネットを作ること。
VPC内にはRouterと呼ばれるルーティン
グを担当するコンポーネントがある。
ルートテーブルを各サブネットに対して
設定することができる。
Publicサブネットのルートテーブルでは、
すべてのアドレスをInternet Gateway向
きに設定することでインターネットとの接
続を可能にする。
Privateサブネットのインスタンスは、
NAT Gatewayを通してインターネットに
接続できるようにすることが望ましい。
0.0.0.0/0 igw
0.0.0.0/0 igw
0.0.0.0/0 natgw
0.0.0.0/0 no setting
インターネットには
出れない

11.
その他、確認しておくといい項目
11
1. セキュリティグループとNetwork ACLについて
2. 責任共有モデル
3. AWS Well Architected
4. AWSサービスの配置場所
AWSではサービスごとに配置される場所が異なる。VPC内部に配置できるも
のや、リージョンにあるのもの、エッジロケーションにあるものなど。
5. オブジェクトストレージのS3
ブロックストレージとは違うので要確認。そしてよく出てくる
参考：万能じゃない。オブジェクトストレージの仕組みと利用を正しく理解する

12.
Kubernetes on AWS
12

13.
マネージドサービスを利用するか自前で構築するか
13
AWS上でKubernetesを構築するには大きく2つの方法がある。
どちらを使うかによって、自分が持つ責任範囲が変わってくる。
1. EC2などを使ってすべて自前で構築する
a. セットアップするためのツールには、Rancherやkubespray, kopsなどがある。
2. Amazon EKSを利用する
a. マスターノードがマネージドサービスとして提供される。
ちなみにKubernetesではないが、Amazon ECSという独自のコンテナオーケスト
レーションサービスもある。

14.
Cloud Controller Manager
14
KubernetesをAWS上にインストールしただけでは、AWSのリソースとの連携は
できない。その連携を担うのがCloud Controller Manager。Kubernetesのインス
トール時にkubeletの起動オプションに--cloud-provider=xxxxと指定することで対
応しているクラウドの場合リソースとの連携が可能になる。
公式ドキュメント：Concepts Underlying the Cloud Controller Manager

15.
Service/Ingressとロードバランサ
15
Kubernetes上に構築したアプリケーション(Pod)をインター
ネットからアクセスできるようにする方法の１つとして、
Service Type=LoadBalancerがある。このServiceを使用
するとAWS上のロードバランササービスELBを利用するこ
とが可能になる。Annotation指定でNLBを利用することも
可能。
また、AWS ALB Ingress Controllerを利用して、Ingressの
リソースも利用してALBを介してPodを外部公開することも
可能。
ELB
WorkerのNodePortへ適当
に振り分け
Node Port
Nginx
Pod
Node Port Node Port

16.
Service/Ingressとロードバランサ
16
https://aws.amazon.com/blogs/opensource/kubernetes-ingress-aws-alb-ingress-controller/
Type=LoadBalancerのServiceとIngressの一番の違いは
処理するレイヤー。
Serviceの場合は一般的にL4処理でIngressの場合はL7処
理となる。
そのため、Ingressでは、TLSの終端やRequest URLや
Pathをベースにルーティングができる。
Type=LoadBalancerのServiceの場合はデフォルトで
CLB(Classic Load Balancer)が、Ingressの場合は
ALB(Application Load Balancer)が利用される。
ALB
Ruleに基づいて、適切な
WorkerのNodePortへに振
り分け。
Node Port
Nginx
Pod
Node Port Node Port

17.
PV/PVCとEBSボリューム
17
10GB 50GB 100GB
EBS
EBS Volumeを事前に用意
Master API
1. 30GBのストレージ
がほしい (PVC)
2. 要求を満たす一番近
いストレージが50GBな
のでこれをあげるよ。
30GB
EBS
EBS Volumeは事前に用意しない
Master API
1. 30GBのストレージ
がほしい (PVC)
3. 30GBのストレージでき
たからこれを使ってね。
2. 30GBのストレージい
ま作るね。(API経由で
EBS Volumeを作る)
通常のPV, PVCのフロー
クラウドの良さを利用した
Dynamic Provisioningのフロー

18.
Auto Scaling Groupを使ったノードの管理
18
Auto ScalingというEC2インスタンスを負荷などに応じてスケールアウト・インする
ことのできるサービスがある。負荷状況に応じたスケールだけではなく、期待する
インスタンス数を維持することにも利用ができる。（スケールアップ・ダウンではな
いので注意）
これを利用して、WorkerノードなどのKubernetesを構成するEC2はAuto Scaling
Groupを作って所属させておくこともできる。なにかしらの原因によってインスタン
スが落ちた場合にもAuto Scalingが期待する台数までもどしてもらえる。
参考としてEKSのアーキテクチャ図でもWorkerノード及び踏み台サーバはAuto
Scaling Groupに所属させている。

19.
なぜKubernetesはAWSリソースを操作できるのか
19
30GB
EBS
EBS Volumeは事前に用意しない
Master API
1. 30GBのストレージ
がほしい (PVC)
3. 30GBのストレージでき
たからこれを使ってね。
2. 30GBのストレージい
ま作るね。(API経由で
EBS Volumeを作る)
クラウドの良さを利用した
Dynamic Provisioningのフロー
【問題】
Dynamic Provisioningの例で、
KubernetesのMaster APIはAPI経由で
EBSボリュームを作っていたわけだが、
なぜKubernetesはAWSリソースを作れ
るのでしょうか？
Kubernetesインストール時にAPI Keyを
もたせている？

20.
なぜKubernetesはAWSリソースを操作できるのか
20
【正解】
マスターノードのEC2にIAM Roleを割り当てている。Kubernetesインストール時
にAPI Keyをもたせることもできるはずだが、一般的にはMaster NodeのEC2に
IAM Roleを割り当てることが一般的。IAM Roleにはどのリソースに対してどのよ
うな操作ができるかの権限が設定できる。
AWSも公式でアクセスキー管理のベストプラクティスとして、IAM Roleを使った
STSの利用を推奨している。（公式ドキュメント）
AWS STS
metadata
IAM Role
ELB EBS
$ curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<rolename>
{
"Code" : "Success",
"LastUpdated" : "2012-04-26T16:39:16Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "ASIAIOSFODNN7EXAMPLE",
"SecretAccessKey" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"Token" : "token",
"Expiration" : "2017-05-17T15:09:54Z"
}1. metadataからクレデンシャルを取得。
右はサンプルリクエスト。
2. クレデンシャルを使って他
AWSリソースを操作。

21.
Q&A（実際にあった質問抜粋）
21
1. AWSの料金は？
各サービスで料金が設定されている。基本的に従量課金。利用した時間や利用した量などによって変動する。一部のサービスにつ
いてはリザーブドインスタンスという一括払いによる割引も受けられる。そのほか EC2においてはスポットインスタンスというものもあ
る。
2. 利用する上での注意点は？
注意点・・・初歩的なことだが APIの鍵の管理は徹底を。あやまって Githubとかにあげると数百万の請求が来てもおかしくありません
よ。あとはセキュリティ関連だと 責任共有モデルというのがあって、AWSとユーザで責任をおう範囲が異なるのでここは要チェック。
他としてはよくハマりやすいのはクオータかな。クラウドといいつつ、無制限にインスタンスをあげられるわけではない。それなりの
大きさのインスタンスだとデフォルトだと数個しか立ち上げられない場合もあるので、台数が必要な場合は事前に申請してクオータ
をあげておくこと。
3. Ingressで作成したALBとRoute53に自動登録することはできる？
やったことないけどできるっぽい。 kubernetesのincubatorソフトウェアのなかに External DNSというのがあった。これを使うことで外
部のDNSとの連携を図れるようです。
4. どうやって勉強したら良い？
Kubernetesのみを動かす上での AWSという意味で言えばあまり高度なことは要求されていないのでドキュメント読んだりで対応で
きそう。ただ、実際は他のサービスと組み合わせたり、お客さんと会話することを考えると、 AWS SA Associateくらいはもっていても
いいのではと感じる。特にエンプラだとネットワークとかダイレクトコネクトとかそのへんの話もいっしょにでてくることも多いです。

22.
Q&A（実際にあった質問抜粋）
22
1. 個人でも始められる？
無料枠もあるので、ある程度は個人でもできる。ただし、 Kubernetesとかやろうと思うとお金かかってしょうがないので立ち止まって
考えたほうが良いと思います。。。
2. 管理者用のネットワークはどう考えたら良い？
よくある構成としては、 VPN(仮想プライベートゲートウェイ )で管理者はVPC内部に入る構成はよくとります。
3. Internet Gatewayの帯域幅制限は？
帯域幅制限はない。だだしこれはもちろん一人で無限の帯域幅を使えるわけではないので注意。（ 公式FAQ）
4. NFS使いたいんだけど？
マネージドサービスであれば Amazon EFSというのがある。