web-dev-qa-db-ja.com

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

現在、小さな趣味のプロジェクトに取り組んでおり、準備ができたらオープンソースにします。このサービスはGoogle Container Engineで実行されています。設定の煩わしさを回避するためにGCEを選択しました。コストは手頃な価格であり、新しいものを学ぶためです。

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

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

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

これまでに試したこと：

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

google-cloud-platformgoogle-compute-enginekubernetes
25
Ruben Ernst

はい、サービスの外部IPを使用します。私が使用したサービスの例：

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でなければならないことに注意してください。

10
ConnorJC

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

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

この コメント は、外部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を介してサービスにアクセスできました

4
derMikey

ポッドが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

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

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

2
willwill

@ConnorJC @derMikeyの回答を正確に私に有効なものに統合するには：

Compute Engine Instanceで実行されているクラスタープールがあるとします。

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インスタンスのパブリックIPを介してアクセスできました34.56.7.001（クラスターIPではありません）

1
micimize

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

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

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

0
Michael Cole