ロードバランサーなしでGoogle Container Engineのポート80および443を公開する

現在、小さな趣味のプロジェクトに取り組んでおり、準備ができたらオープンソースを作成します。このサービスはGoogle Container Engine上で実行されています。GCEを選んだ理由は、構成の手間を避け、コストが手頃で、新しいことを学ぶためです。

ポッドは正常に動作LoadBalancerしています。ポート80および443でサービスを公開するタイプのサービスを作成しました。これは完全に機能します。

しかし、LoadBalancerサービスごとに新しいGoogle Compute Engineロードバランサーが作成されることを発見しました。このロードバランサーは非常に高価であり、単一のインスタンスの趣味のプロジェクトでは本当にやり過ぎです。

コストを削減するために、ロードバランサーなしでポートを公開する方法を探しています。

私が今までに試したこと：

• NodePortサービスを展開します。残念ながら、30000未満のポートを公開することは許可されていません。

• Ingressをデプロイしますが、これによりロードバランサーも作成されます。

• 無効にしようとしましたHttpLoadBalancing（https://cloud.google.com/container-engine/reference/rest/v1/projects.zones.clusters#HttpLoadBalancing）が、ロードバランサーを作成します。

ロードバランサーなしでGoogle Container Engineの単一インスタンスのポート80と443を公開する方法はありますか？

はい、サービスのexternalIPを介して。私が使用したサービス例：

apiVersion: v1
kind: Service
metadata:
  name: bind
  labels:
    app: bind
    version: 3.0.0
spec:
  ports:
    - port: 53
      protocol: UDP
  selector:
    app: bind
    version: 3.0.0
  externalIPs:
    - a.b.c.d
    - a.b.c.e

構成ファイルにリストされているIPはGCEの内部IPでなければならないことに注意してください。

ConnorJCの優れた実用的なソリューションに加えて、この質問でも同じソリューションが説明されています。 。Kubernetes-GCEロードバランサーを使用してコストを削減することはできますか

「internalIp」は、コンピューティングインスタンス（またはノード）の内部IPを指します（Google Cloud Platform-> Google Compute Engine-> VMインスタンスに表示されます）

この コメントは、外部IPではなく内部IPを構成する必要がある理由を示しています。

さらに、ポート80および443のサービスを構成した後、インスタンスノードへのトラフィックを許可するファイアウォールルールを作成する必要がありました。

gcloud compute firewall-rules create your-name-for-this-fw-rule --allow tcp:80,tcp:443 --source-ranges=0.0.0.0/0

このセットアップ後、http（s）：// externalIpを介してサービスにアクセスできます。

ポッドが1つだけの場合は、これを使用hostNetwork: trueしてこれを実現できます。

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: caddy
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: caddy
    spec:
      hostNetwork: true # <---------
      containers:
      - name: caddy
        image: your_image
        env:
        - name: STATIC_BACKEND # example env in my custom image
          value: $(STATIC_SERVICE_HOST):80

これにより、ポッドは KubernetesではなくホストのDNSリゾルバーを継承することに注意してください。つまり、クラスターサービスをDNS名で解決できなくなります。たとえば、上記の例staticではhttp：// staticでサービスにアクセスできません。環境変数によって注入されたクラスターIPによって引き続きサービスにアクセスできます。。

このソリューションは、kube-proxyをバイパスするため、サービスのexternalIPを使用するよりも優れており、正しいソースIPを受け取ります。

@ConnorJC @derMikeyの答えを、私にとって何がうまくいったのかを正確に合成するには：

Compute Engineインスタンスで実行されているクラスタープールがある場合：

gce vm name: gke-my-app-cluster-pool-blah`
internal ip: 10.123.0.1
external ip: 34.56.7.001 # will be publically exposed

私はサービスを作りました：

apiVersion: v1
kind: Service
metadata:
  labels:
    app: my-app
  name: my-app-service
spec:
  clusterIP: 10.22.222.222
  externalIPs:
  - 10.123.0.1 # the instance internal ip
  ports:
  - port: 80
    protocol: TCP
  selector:
    app: my-app
  type: ClusterIP

そして、プロジェクト内のすべての（？）IPに対してファイアウォールを開きました。

gcloud compute firewall-rules create open-my-app --allow tcp:80,tcp:443 --source-ranges=0.0.0.0/0

そしてmy-app、GCEインスタンスのパブリックIP34.56.7.001（クラスターIPではなく）を介してアクセスできました

コストとベンダーロックインのため、必要になるまでクラウドロードバランサーを使用しないことを好みます。

代わりにこれを使用します：https : //kubernetes.github.io/ingress-nginx/deploy/

ロードバランサーを実行するポッドです。そのページにはGKE固有のインストールノートがあります。