로드 밸런서없이 Google 컨테이너 엔진에 포트 80 및 443 노출

현재 소규모 취미 프로젝트를 준비 중이며 일단 준비가되면 오픈 소스를 만들 것입니다. 이 서비스는 Google 컨테이너 엔진에서 실행되고 있습니다. 구성 번거 로움을 피하고 비용이 저렴하며 새로운 것을 배우기 위해 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 컨테이너 엔진의 단일 인스턴스에 대해 포트 80 및 443을 노출하는 방법이 있습니까?

서비스의 외부 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 여야합니다.

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를 통해 서비스에 액세스 할 수 있습니다

포드가 정확히 하나 인 경우 다음 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

그런 다음 프로젝트에서 all (?) ips에 대한 방화벽을 열었습니다.

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

그런 다음 GCE 인스턴스 퍼블릭 IP (클러스터 ip가 아님) my-app를 통해 액세스 할 수있었습니다.34.56.7.001

비용과 공급 업체 잠금으로 인해 필요할 때까지 클라우드로드 밸런서를 사용하지 않는 것이 좋습니다.

대신 나는 이것을 사용한다 : https://kubernetes.github.io/ingress-nginx/deploy/

로드 밸런서를 실행하는 포드입니다. 이 페이지에는 GKE 관련 설치 정보가 있습니다.