momota.txt

hello, hello, hello, how low?

[参加レポート]Google Cloud Kubernetes Day

  • 2019/03/26(火)、渋谷で行われた Google Cloud Kubernetes Day への参加レポート。
  • 会場の約半数が k8s をすでに利用、サービスメッシュは1割程度という感じで、プロダクション環境での採用をやっていかないとまずいという雰囲気だった。
  • ハッシュタグ: #gc_k8sday
  • 資料が公開されたらリンクを張ったりアップデートする予定。

「Kubernetes/Container による開発」の導入難易度とメリット

  • 株式会社サイバーエージェント　青山 真也 氏

  • @amsy810

  • サイバーエージェントとk8s

  • k8s
    • コンテナオーケストレーションシステムの一つ
    • Google のクラスタマネージャ Borg ベースなので、Googleの経験がk8sに引き継がれている
    • 現在はCNCFが中立的にホスト。コミュニティによって改良されている。
  • オーケストレーションとは
    • プロビジョニングの一つ
      1. ブートストラッピング: サーバの準備、OSのインストール
        • Terraform
      2. コンフィグレーション: サーバのセットアップ、ミドルウェアのインストール、セットアップ
        • Chef, Ansible, Puppet, Salt
      3. オーケストレーション: アプリケーションの配置
        • Fabric, Capistrano
    • イメージ化による高い再現性を保つようになってきた
      • Packer, Cloud Image, OpenStack Heat, CloudFormation
    • 容易なイメージ化、軽量なイメージ、高速な起動と停止。特定クラウドへの依存がない。
      • Docker, k8s
  • Cloud Nativeとは
    • 疎結合なシステム
    • 復元力がある
    • 管理しやすい
    • 可観測である
    • 堅牢な自動化により、頻繁かつ期待通りに最小限の労力で大きな変更が可能
  • CNCF が Cloud Native の進め方をTRAIL MAPとして定義: cncf/landscape

CNCF trail map

Containerization

レガシーシステムのマイグレーションもスタート地点はここから。実行環境込みのアプリケーションをSystemdに置き換えるイメージ

  1. 容易なイメージかと再現性 by Docker
    • アプリケーションと実行環境のイメージ化: 再現性の高い環境
    • OCI v1.0 によるポータビリティ
    • ローカル環境でも同等の動作が保証される
  2. 軽量なイメージ by Docker
    • VMイメージと比べて軽量
    • 単一プロセスのみを可動させるため、軽量OSの選定もしやすい: Alpine
  3. 高速な起動と停止 by Docker
    • VMよりも起動停止が高速: プロセスの起動停止に相当
    • 高速なスケールアウトや障害時の復旧が可能

Orchestration

  1. 高い抽象度とクラウド非依存 by k8s
    • Load BalancerやStorageなども抽象化
    • 利用者から見るとクラウド固有の知識がほぼ不要 vs Terraform, OpenStack heat, AWS CloudFormation
    • ベンダーニュートラルな実行基盤
    • 基本的にはポータビリティがある
  2. 宣言的なAPIとCode by k8s
    • 構成情報はManifestsで宣言的に記述してAPIに登録: Infrastructure as Code
      • $ kubectl apply -f manifest.yaml
    • Control LoopとReconciliation: 以下の処理を繰り替えす→ Control Loop
      1. 現在の状態を観測
      2. 現在の状態と理想状態を比較
      3. 差分に対する処理を実施 (Reconcilation)
  3. 洗練された自動化 by k8s
    • 障害時のセルフヒーリング
      • ReplicaSet ではコンテナの Replica 数を維持し続ける
      • 障害などでコンテナが不足した場合は、別の Node 上で高速に起動
    • アプリケーションのアップグレード
      • ロードバランサからの除外
      • コンテナイメージのアップデート
      • ロードバランサへの追加
    • コンテナ単位のヘルスチェック
    • コンテナ起動前の初期化処理
    • コンテナ停止時のSIGNAL
    • コンテナ開始直後、停止直前のフック
  4. 豊富なエコシステムと拡張性 by k8s
    • CNCF landscape
    • 例
1
2
3
4
5
6
7
8

# MySQL Cluster on Kubernetes
apiVersion: mysql.oracl.com/v1alpha1
kind: Cluster
metadata:
  name: mysql
spec:
  multiMaster: true
  members: 3

1
2
3
4
5
6
7
8
9
10
11
12
13

# CI/CD on Kubernetes
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: hello-world-
spec:
  entrypoint: whalesay
  templates:
  - name: whalesay
    container:
      image: docker/whalesay:latest
      command: [cowsay]
      args: ["hello world"]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# Serverless on Kubernetes
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: hello-world-go
  namespace: default
spec:
  runLatest:
    configuration:
      revisionTemplate:
        spec:
          container:
            image: docker.io/{username}/hello-world-go
            env:
            - name: TARGET
              value: "Go sample v1"

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# Service Mesh on Kubernetes
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subnet: v1
      weight: 50
    - destination:
        host: reviews
        subnet: v3
      weight: 50

1
2
3
4
5
6
7
8
9
10
11
12

# Managed Service via Kubernetes (Cloud SQL)
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServiceInstance
metadata:
  name: db
spec:
  clusterServiceClassExternalName: cloud-sql-mysql
  clusterServicePlanExternalName: beta
  parameters:
    instanceId: sample-cloudsql
    databaseVersion: MYSQL_5_7
    region: asia-northeast1

1
2
3
4
5
6
7
8

# YOUR FEATURES with Kubernetes
apiVersion: amsy.dev/v1beta1
kind: MyResource
metadata:
  name: my-resource
spec:
  name: MasayaAoyama
  replicas: 1

Cloud Nativeの難しさ

  1. アプリケーションのアーキテクチャ
    • マイクロ/ミニサービスに適した技術
    • いつでも停止できるようにSIGTERMのハンドリングは必須: ノードのアップグレード、コンテナイメージのアップデート
    • Service Discovery経由で通信
    • ネットワークに一部制約がある (Source IPが消失する、など)
  2. セキュリティと分離性
    • 仮想化の分離性
      • runC (標準の Docker) では Kernel を共有
      • gVisorなど分離性の高い Container Runtime を利用する
    • ネットワークの分離性
      • Network Policy を利用できない環境ではコンテナ間の通信は筒抜け
  3. k8sの学習コスト
    • 学習コストは小さくないものの懸念するほどではない
  4. k8sクラスタの運用
    • 一番つらいのは k8s クラスタの管理
      • etcd のバックアップ
      • Kubernetes Master のスケールアップ
      • Kubernetes バージョンのアップグレード
      • Kubernetes クラスタのオートスケール
      • 障害時のノード復旧
      • コンテナランタイム (Docker/ runC) の管理
      • OS (Kernel) の管理、など
    • マネージド Kubernetes サービス GKE を利用することでだいぶ楽できる

マネージドk8sの選定基準

  • マネージドの範囲
  • クラスタマネジメントの自動化機能
  • k8sバージョンの追随スピード
  • 他のマネージド・サービスとのインテグレーション
  • ネットワーク周りの要件
  • その他: virtual-kubelet の対応など

サイバーエージェントと GKE

  • サイバーエージェントでは、アドテク分野やアベマTVなどいろいろなヘビーワークロードにもk8sで実装し、耐えうるシステムを構築
  • ステートフル部分はマネージドサービスを利用する: Cloud Storage, Cloud SQL、BigQuery、…

コンテナ開発プラットフォームに GKE を選択すべき 7 つの理由

  • Google Cloud Japan　田中 宏樹氏、岩成 祐樹氏

Security

  • セキュリティがクラウドの長所に

  • GCPでは、徹底的な防御がデフォルトでON

    • 通信の暗号化
    • ストレージの暗号化
    • 認証・認可
    • ハードウェア

  • コンテナのセキュリティとは

    • インフラストレクチャセキュリティ: インフラはコンテナを開発するのに安全か
      • k8s のセキュリティ機能を使って、ID, シークレット, ネットワークをどのように守るか
      • GKEに備わるIAM, audit logging, networkingなどの機能をどのように活用するか
    • ソフトウェアサプライチェーン: 作成したコンテナはビルド、デプロイして問題ないか
      • コンテナイメージに脆弱性がないことをどのように保証するか
      • ビル出されたイメージが、デプロイまでに改ざんされないことをどのように保証するか
    • ランタイムセキュリティ: 作成したコンテナは実行して問題ないか
      • コンテナが不審な挙動をしたときにどのように検知するか
      • その際、ワークロードをどのように守り、分離するか
      • どのようにコンテナのデプロイを安全にスケールさせるか

  • コンテナセキュリティの脅威とリスク

インフラストラクチャセキュリティ ソフトウェアサプライチェーン ランタイムセキュリティ
権限昇格 パッチ適用漏れによる脆弱性 DDoS
機密情報の漏洩 サプライチェーンに聞いする脆弱性 Node への不正アクセス
Kubernetes API の漏洩 共通ライブラリのゼロデイ脆弱性 Container escape
必要以上の権限を持つユーザ Flood event pipline
  • コンテナのセキュリティ
    • GKE: Use RBAC and IAM
      • プロジェクトレベルでIAMを利用
      • クラスタ/ネームスペースレベルでRBACを利用
    • プライベートクラスタと承認済みネットワーク
    • Cloud Armor: スケーラブルなDDoS対策/WAF
    • BackendConfg
      • Kubernetes Engine Ingress controller で利用されるカスタムリソース定義
      • BackendConfig オブジェクトとサービスポートを紐付けることで、GCLB 用の設定が可能
      • GKE version 1.10.5-GKE.3 以降で利用可能
    • ソフトウェアサプライチェーン
      • CI/CDパイプラインは信頼できないデプロイを止めてくれない
        • イメージのメタデータ
        • Binary Authorization: QAされたコードだけを実行
      • Container Registry: 脆弱性スキャン
        • Ubuntu, Debian, Alpineのパッケージにある脆弱性を特定
        • 常時更新されるデータベースにより、スキャンが常に最新であることを保証
        • 検出可能な脆弱性を拡張するために、既存のツールをプラグインすることが可能
      • Binary Authorization: 信頼されたコンテナイメージのみをGKE上にデプロイすることを保証するセキュリティコントロール機能
        • 検証済みイメージのみが、ビルドリリースプロセスと統合可能
        • 開発中に信頼された認証局により署名されたイメージが必要となる
        • Kubernetes Engineにデプロイする前にシグネチャの検証を矯正することが可能
    • ランタイムセキュリティ
      • Container Optimized OS: GCE, GKEで利用可能な軽量なイメージ
        • runcの脆弱性 CVE-2019-5736の影響を受けなかった
      • Runtime security partners in Cloud SCC: 3rdパーティツールの利用
        • Cloud Security Command Center
        • aqua, capsule8, stackrox, sysdig, twistlock…

Network

  • さまざまなGCPサービスとの統合
  • Google Cloud Load Bakancing
    • 世界で一つのエニーキャストアドレスに対するリクエストを、複数のリージョンにまたがってデプロイされたGKEクラスタに対してルーティングすることが可能
  • 世界中のCloud CDNとLB
    • 9 つのリージョン、27 のゾーン、100 以上の接続ポイント（POP）、および延べ数十万 km に及ぶ光ファイバーケーブルで構築され、適切にプロビジョニングされたグローバルネットワーク
  • Container Native Load Balancing
    • LBからVM(Node)を介さずPodへ直接トラフィックを転送
    • Double-hop問題を解決
    • レイテンシーとルーティング性能問題を解決
    • VPC-native clusters かつ Kubernetes version 1.10+ で利用可能

Hybrid Cloud

  • ゴール: コードをどこでも実行できる環境を整える
  • GKE On-prem
    • オンプレミスのクラスタをGoogle Cloud Consoleから一元的に管理
    • クラスタ集中管理のメリット: GKEとGKE On-Premで同じツールを使ってクラスタの構築、構成、管理を実施
    • 同一のクラスタ環境
  • 事例
    • メルカリ: オンプレミスからの移行

Observability

  • ロギング
    • 複数のアプリケーションやサービスから発生するログの収集
    • GCP内部の情報に加えて、GCPの外部で発生するログについても収集できる基盤が必要
  • モニタリング
    • 収集したtログや指標を見える化し、アクションを提供する一連のプロセス
    • アプリケーションのエラーが発生したり、しきい値を超えた際に、アラートを適切な担当者に正しく送る機能が必要
  • 統合管理プラットフォーム
    • DevOpe/SRE: パフォーマンスの問題を調査するためには、すべてのクラスターの状況の理解が必要
    • Developer: 最良のシステムを構築するためには、インフラストラクチャ、ワークロード、サービスを継続モニタリングが必要
    • SecOps: セキュリティポリシーを見直してコンプライアンスを強化のため、すべてのクラスタの監査ログの収集が必要
  • Stackdriver: アプリケーション開発者と運用担当者にLoggingとMonitoring機能を提供する
  • Stackdriver Kubernetes Monitoring
    • k8sのワークロードに最適化されたStackdriverのツール
  • work with Open Source: Prometheus
    • Google にインスパイアされたエンジニアが Prometheus イニシアティブをリード
    • Open Source の Prometheus と、Stackdriver k8s Monitoring のシームレスなインテグレーション

Contribution

  • Open source is free like a puppy
  • GKE is going to ..
    • To be Reliable
      • Regional clusters
        • Kubernetes コントロールプレーンを3つのゾーン (同一リージョン) で実行する
      • Regional Persistent Disks
        • セカンダリゾーンの Disk に対してデータをミラーリング
        • ゾーン障害時、GKEはコンテナを問題のないゾーンにマイグレーション、強制的にミラーリングしてある Disk をアタッチ
    • To be Scalable
      • HPA: Pod の水平スケーリング
      • VPA: Pod の垂直スケーリング
      • CA: Node の水平スケーリング
      • Node Auto-Provisioning
    • To be Open
      • OSS Friendly ecosystem
        • Skaffold
        • Kanico
        • Knative

GKE を用いたレガシー システムからのリプレース事例

  • 富士フイルム株式会社　小林 大助 氏

プロジェクト概要

GKE利用までの経緯

  • S→T→P→D→C→A
    • PDCAに加えて See + Think
    • 富士フィルムではSTを重視
    • 現状分析をしっかり行い、目的を明確にする
  • モノリシックなアプリケーションにより影響範囲の見定めが難しい
  • 特に苦労しているのは季節イベント、キャンペーン
    • 負荷量の変動に対してシステムが追随しにくい
    • スケーラビリティを確保しやすい仕組みを最優先にする
    • コンテナを採用
  • 保守面を意識すれば、オーケストレーションツールは使いたい。課題が2つ
    • 何が標準か
      • 流行度
      • [社内の]覇権争い
      • 仕様策定中
    • 自分たちで運用できるか
      • 使いこなせないと意味がない
      • 運用環境に耐えうるレベルか
  • k8sがデファクトスタンダードになった: 規格争いによる技術の陳腐化懸念が後退
  • 主要ベンダがk8sマネージドサービスを展開: コンテナやオーケストレーションツールが動作する環境を自前で準備する必要がなくなり、安定動作する環境が整いつつある
    • 2018年1月時点で日本国内GAしているのはGoogeのみ
    • 動作安定性: k8s の開発元であること、コンテナを先取りしている取り組み、4年以上の安定動作運用実績があることから信頼性が高い。完全にコンテナ化できない部分でもライブマイグレーション機能の強みを活かせる

取り組む上での課題: 組織面

  • 周囲の理解
    • コンテナやオーケストレーションツールに対する周囲の理解を深めなければならない
    • 技術的優位性を説明できないといけない
    • 総論は賛成、各論は？
    • リスクを背負えるか: 納期遵守のPrj
    • 所属部門・関係部門の合意を取り付ける必要あり
  • 近道はなし: 技術学習、解説資料作成、説明行脚
  • 現場レベルでは味方は多かった: 技術学習の協力や相談が効率化。求めるところが同じがゆえの連帯感。
    • プロジェクトメンバー
    • インフラエンジニア
    • 部門横断のエンジニア
  • リスクに対しては、バックアッププランの準備、技術習得状況の説明、Googleエンジニアのバックアップ

取り組む上での課題: 開発面

  • 技術習得: 独学とハンズオン
  • 事前調査
    • レガシーシステムのルール把握: どの程度引きずられるか、実施してから発覚した問題あり
    • 効率的なシステム間連携に知識が必要
      • Pub/Sub 連携のイベント発火条件も当初は無駄が多かったプログラムか、サービス活用かの見極め
        • 当初案: プログラム制御でイベント発火
        • 対応案: ファイル配置 → Cloud Functions で配置イベント検知 → Pub/Sub 投げ込み、のように分離
  • 運用: ログ出力やアラート関連は、メトリクスの書き方が困難だった
  • 設計・設定: マニフェストファイルの書き方、永続データの取扱いに関する適切なサービス選定がむずい
  • 基本設計: サービス分割はアトミックにすると障害復旧が難しいので、意味のある塊に
  • 商用利用に向けての課題: PaaSの特徴や仕様についてGoogleエンジニアのサポートを受けながら選定、確認を進める
  • レガシーシステムとの連携
    • レガシーシステム側を変えることは難しく、ルールに従う必要あり (IP制限、連携方法の指定など)
    • 基本は新システム側が全面降伏で対応: もともと予定していなかったインフラ構築やネットワーク設定が追加

効果

  • スケーラビリティの確保はできた。ただし、今後悪化しないように管理していく必要がある
  • 保守運用コストは改善された
    • モノリシックな構造を改善し、影響範囲を縮小できた。機能搭載費用 1/2に
    • サーバリソースの有効活用によりランニングコスト 3/5に
    • 導入8ヶ月でサービスダウンタイムなし。安定稼働中。
  • 機能改善スピードは向上できた
    • 対応速度が約2倍に
  • 学習コストは小さくなかったが、リターンが大きかった
  • アプリ開発に集中できる環境を整えることができた
  • 組織の壁は高い、乗り越えるには熱意が必要。仲間がいれば突破しやすい
  • クラウドベンダエンジニアの協力は偉大

コンテナによる開発と運用の進化

  • Google Cloud Japan　篠原 一徳氏、村上 大河氏

  • 3つのポイント

    • 人 (ビジネス・技術)
      • CxO
      • Manager
      • Business
      • Tech
    • プロセス
      • DevOps
      • SRE
      • Scrum (アジャイル開発)
      • Waterfall
    • テクノロジー
      • クラウド
      • マイクロサービスアーキテクチャ
      • CI/CD
  • マイクロサービスとは
    • 2014年にJames LewisとMartin Fowlerが提唱
    • 機能ごとに独立したアプリケーションに分割
    • 各サービスは単一の目的を持つ
    • 分散システム、サービス間は疎結合、軽量なAPIなどでやりとり
  • AsIs to ToBe: Monolith to Microservice
    • 新規サービスからやる (新規機能から抜き出す)
    • 既存のサービスを部分的に置き換える
      • Domain (専門領域) を抜き出し、マイクロサービス化する
      • チームも抜き出していくことが重要
  • マイクロサービス化を進めていくと、カオス化
  • The problem
    • 分散アーキテクチャへの移行により、今までのアーキテクチャ向けに最適化された方法では監視、管理、保護が困難
  • 4 challenges of Microservices
    • プロセス内のコミュニケーションから、プロセス外コミュニケーションへの置き換え: RPC + APIゲートウェイ
    • 分散システム導入により複雑化するシステムの効率的な管理: サービスメッシュ
    • マイクロサービス協会が引き起こすデータサイロの解決: データレイク
    • アプリケーションコード以外のコーディングを少なくする: 自動化 (CI/CD)
  • 課題と2つの実現方法
    • 呼び出し先マイクロサービスのトラッキングが困難
      • REST API (HTTP1.1)
        • Open APIでメッセージフォーマットを定義
        • 互換性管理のためのガイドラインの作成を推奨
      • gRPC (HTTP2.0)
        • Protocol Buffersでメッセージフォーマットを定義
        • Language Guideに従うと、下位互換性の担保が容易
    • バージョン管理ガイド
    • API設計ガイド
    • Cloud Endpointsによるマイクロサービスの実現
      • 内部はgRPC、外部はRESTで公開も可能
  • サービスメッシュ
    • マイクロサービス環境において、サービスディスカバリ、トラフィックコントロール、認証・認可、メトリクス収集などの機能を担うソフトウェア
    • アプリケーション自体に手を入れるのではなく、サイドカーで実現
    • Istio: GoogleとIBMが中心に開発しているサービスメッシュ実装のOSS
      • ProxyとしてEnvoyを利用
      • トラフィックコントロール
        • これまでトラフィックコントロールはインフラストラクチャと結びついていた
        • トラフィックスプリッティング
      • セキュリティ
        • サービス間のセキュリティを強化
        • RBAC
      • 可観測性
        • Istioの監視
          • Mixer: テレメトリの収集
          • Prometheus: Mixer から提供される Istio メトリクスの保存と検索
          • Grafana: ダッシュボードでメトリクスの可視化
          • Jaeger: トレース情報の取得
          • Kiali (addon): サービスグラフの管理
    • Istio on GCP
  • データレイク
    • マイクロサービスにより、データのサイロ化が進む
    • そのとき、どのようにデータを伝送すればよいか
    • また、ビジネス要件である分析も行いたい
  • CSM (Managed Istio) の Alphaユーザを募集中: https://docs.google.com/forms/d/1Qhj4qViWgaSAf9KUfowWRdVS6OHwg9cgEdYX2xbpLeM/viewform?edit_requested=true

FreakOut の広告プロダクトでの GKE 活用事例と GKE 新機能の導入について

  • 株式会社フリークアウト　西口 次郎 氏

  • RED: Freakout DSP

  • ASE: 位置情報マーケティングプラットフォーム
  • RED for Publishers: アドネットワーク基盤
  • LayApp: アプリエンゲージメントプラットフォーム

プロダクション環境でのGKE運用

  • Google Cloud Platform Japan 公式ブログ： 株式会社フリークアウトの導入事例： フルマネージドな Kubernetes Engine を駆使して、大規模アドプラットフォームをプレミアム メディア向けに提供
  • GKE
    • サービスごとにクラスタを分割
    • 広告配信、UI、バッチ
    • CronJob (>= k8s 1.8) を利用
    • カナリーリリース環境を用意
    • Stackdriverを活用
  • Stackdriver
    • Monitoring
      • Prometheusと併用
      • Grafana 5.3 で Stackdriver Datasource を利用中
    • Logging
      • コンテナのエラーログなどを集約
      • アラート: Pub/Sub → Cloud Functions → Slack
    • Profiler
      • 常に最新のコードのプロファイルを可視化、比較
  • BigQuery
    • すべてのアクセスログ、アプリケーションログを集約
      • 数十億レコード/日
    • fluentd (Sidecar Container)からStreaming insert
      • リアルタイム集計
    • 可視化はre:dashを利用
    • MySQLのマスタデータもインポートしている
  • Vulnerability scanning
    • GCRの機能
    • Debian, Ubuntu, Alpineが対象
    • 過去30日間にpullされたイメージが対象
    • 脆弱性が見つかった際、Pub/SubにPublishされる (Cloud FunctionsでSlack通知)
  • kustomise
    • k8s のYAMLファイルのカスタマイズ
    • kubectrlのサブコマンドとしてマージされた
    • Production/Staging/Cannaryなど環境ごとの設定を上書き
      • Replicas
      • 環境変数
      • ConfigMap
  • Other tools
    • stern
      • 複数のコンテナのログをすばやく確認できる
    • kubectx
      • クラスタ切り替え
      • 複数クラスタ/開発・本番環境の切り替えに
      • ネームスペースの切り替えも可能

GKEでのCI/CD

  • Github
  • CircleCI
  • Cloud Build
  • Cloud Container Registry
  • Cloud Pub/Sub: ビルド通知
  • Cloud Functions: Slack通知
  • Slack: エンジニア通知

CIのフロー

  1. GithubへのPush
  2. テスト・ビルド
    • CircleCIでのテスト
    • CloudBuildでのビルド
  3. カナリアリリース

CDのフロー

  1. GithubでPRをマージ
  2. ビルド&デプロイ
    • docker build
    • docker push (to Container Registry)
    • kubectrl set image
  3. notification
    • Pub/SubへのPublish
    • Cloud FunctionsでSlack通知

GKE 新機能の利用

  • VPC-native cluster (alias IP)
    • Cloud Memorystore for Redis の利用が可能
    • Cloud SQL Private IP に接続可能
  • Cloud NAT
    • マネージドNATサービス
    • アウトバウンドアクセスのゲートウェイ
    • 外部アクセスするIPアドレスを限定する用途で使用
      • IPアドレスの事前登録が必須な外部API
  • Network Endpoint Groups (NEGs)
    • コンテナネイティブの負荷分散
    • Instance Groupはiptablesを介してPodへルーティングしていたが、Podへ直接ルーティング可能
    • ネットワークパフォーマンス改善
    • 要 VPC-native cluster
    • Service アノテーション cloud.google.com/neg に { "ingress": true } を指定する
  • BackendConfig Custom resource
    • GKE Ingressコントローラのカスタムリソース定義
      • Balancer Settings
      • Cloud Armor
      • Cloud IAP
      • Cloud CDN
    • Service と BackendConfig を紐づけて使用する
      • Service アノテーション beta.cloud.google.com/backend-configs

Comments