個人的なメモです。

前書き

courseraのNetworking in Google Cloudは、以下のコースを含む

[1]Basics

１つのプロジェクトは複数のネットワークを持ちうる。ネットワークはregionをまたげる。同一ネットワーク内なら、internal IPアドレス指定でやりとりできる。
- ネットワークを跨いだとしても、GCP間の通信なら(実はインターネットを経由せず)google edge router経由で external IPアドレス指定でやりとりしている。
デフォでsubnetは、regionごとに１つ作られる(subnetはregionをまたげない)。
subenet同士はWANで繋がっている。
subnet内で、x.x.x.0はネットワーク用に、x.x.x.1はゲートウェイ用に、あと２つなんらかのために確保される。

internalIPとexternal IPのマッピングは、VPCでlookup tableによって行われる。

インスタンスのOSは自分のinternal ipがなにかを知っている。(see: /sbin/config)
DHCPによってsubnetのレンジの中からIPアドレスが１つがVMに与えられる。ドメイン名(FQDNは[hostname].c.c[project-id].internal)とIPの組み合わせがnetwork-scoped DNSに登録される。
IPアドレスはephemeralだが、ドメイン名はインスタンスをstopしても不変である。
alias ip rangesを使うことで一つのインスタンス上で動く複数のサーバに異なるIPアドレスを振ることができる。(もちろんsubnetのレンジ内のものを使用可能)

cloud routesがルーティングテーブルを持っており、これはネットワークやサブネットが作られたときに作られる。
ルーティングテーブルは、以下の情報を含む。
- (1)各サブネット(のインスタンス??)へのルーティング
- (2)デフォルトゲートウェイ(0.0.0.0)へのルーティング

インスタンスごとに付与される。in/out X from/destination X protocol

デフォで以下が許可される。(以下のネットワークとはサブネットではない！っぽい)

優先度下がって、

VPCネットワークをまたいでinternal IPアドレスでやりとりするためには、VPC peeringかVPNという方法を使う必要がある。

インスタンスは、デフォルトのnetwork interfaceを持っており、さらに特定のnetworkに接続するためのnetwork interfaceを追加することができる。これにはNIC(= network interface controllers)を用いる。(subnetのレンジは全てユニークである必要がある)
一つのインスタンスはnetwork interfaceを最大８つもつことができる。それぞれのinterfaceに、繋ぎ先のsubnetのIPアドレスのレンジ内のinternal IPアドレスが一つ紐づけられている。
- ８つと書いたが、インスタンスのcpuのコア数などによって左右される。
network interfaceは、インスタンス作成時にしか設定できない。インスタンスを削除する以外に消す方法はない。

orgを跨ぐことすらできる。
external IP addressでやりとりするよりも、Network Latency低い, Network Security高い, Network Cost低いという利点がある。
subnetのrangeが被ったらダメ
ネットワークAとBをpeeringするためには、peering-A-Bとpeering-B-Aの二つの設定が必要である

同じOrgの別プロジェクトでVPC Networkを共有(することでinternal IPアドレスを指定してやりとり)したい。このために、一つのHost Projectに、他のService Projectsをattachする。これによって、shared VPC network(xpnとも)を作成する。このために、host projectに???必要なのは
- Organization admin role (多分userに対して??)
- Shared VPC admin (hostにもserviceにも??) = Compute Nework Admin roleに含められて付与される
- Service Project admin role

以下の６種類。

Global
- HTTP(S)
- SSL Proxy
- TCP Proxy
Regional
- Internal TCP/UDP (powered by Andromeda)
- Network TCP/UDP (powered by Maglev)
- Internal HTTP(S) (using proxy-based Layer 7ロードバランサ)

以下まとめて一つのバランサ。BackendServiceとBackendは異なることに注意。

HTTPSロードバランサだと、 target HTTPS proxyを使う。このproxyは、最低1つ(最高10)のSSL証明書を持っている必要がある。
Cloud Armorを導入することで、「特定のIPを弾く」などのsecurity policyを作成できる。作成時に、backend serviceに紐づけられる。
Backendとして、Cloud Storageを使用することもできる。load balancerでbackendとしてこれを選択するときに、Enable Cloud CDN.を選択するだけで、CDNを使ったキャッシュが有効になる！(初回のリクエスト時は「まずCDNにリクエストし、キャッシュミスが発覚して、ロードバランサに転送される」という流れ。)

ちなみに、同一region内の、同一ネットワークからのinternalなインスタンスからリクエストは以下のように裁いている。
(同一のregion)

一つのテンプレ(設計図)をもとに、複数のコピーとなるインスタンスを立ち上げられる。ローリングアップデートや、ロードバランシングの負荷調整の際に使用される。

(新たに記事作るのもアレなのでここに入れてしまう)

IAM policyでは、階層の下に行くほど、権限が足し算されていく。(ので、上の回想で権限を与えすぎるな)
IAM roleは、
- Basic Roles = Owner > Editor > Viewer (順に包含される) / BillingAdminstrator
- Predefined Roles = list of permissionsで、名前がついている (Network viewerとか、network adminとか、security adminとかshared VPCとか)
- Custom Roles
Security admin roleはfirewallを含む全てのネットワークリソースのlistとCRUDが、Network admin roleはfirewallを含まないリソースのlistのみができる