Kubernetes Ingress VS OpenShift Route

팟(Pod)과 서비스는 Kubernetes에 고유한 IP 주소를 가지고 있지만 이러한 IP 주소는 Kubernetes 클러스터 내에서만 연결할 수 있고 외부 클라이언트에서는 액세스할 수 없습니다. Kubernetes 의 Ingress 개체는 아직 베타 버전이지만 외부 세계에서 특정 서비스에 액세스할 수 있어야 하며 여기에는 외부에서 연결할 수 있는 URL, SSL 등과 같은 필요한 구성이 포함되어 있음을 Kubernetes 플랫폼에 알리도록 설계되었습니다.

인그레스 객체 생성은 그 자체로 어떤 영향도 미치지 않아야 하며 인그레스 객체에 의해 정의된 구성을 수행하기 위해 Kubernetes 플랫폼에 인그레스 컨트롤러가 필요합니다.

여기 Red Hat에서 우리는 Kubernetes에 수신 객체를 도입하기 전에 서비스에 대한 외부 액세스를 활성화할 필요성을 확인하고 동일한 목적을 위해 Route 라는 개념을 만들었습니다 (여러 백엔드 간 트래픽 분할, 고정 세션 등과 같은 추가 기능 포함). ). Red Hat은 Kubernetes 커뮤니티의 최고 기여자 중 하나이며 Ingress 디자인에 큰 영향을 준 커뮤니티에 대한 Routes 이면의 디자인 원칙에 기여했습니다 .

Route 개체가 OpenShift에서 생성되면 요청된 서비스를 노출하고 지정된 구성으로 외부에서 사용할 수 있도록 하기 위해 기본 제공 HAProxy 로드 밸런서 에 의해 선택됩니다. OpenShift가 이 HAProxy 기반 내장 로드 밸런서를 제공하지만 관리자가 이를 NGINX(및 NGINX Plus) 또는 F5 BIG-IP 와 같은 외부 로드 밸런서로 교체할 수 있는 플러그형 아키텍처가 있다는 점은 언급할 가치가 있습니다 .

이 시점에서 이것이 혼란스럽다고 생각할 수도 있습니다! 표준 Kubernetes ingress objects를 사용해야 합니까 아니면 OpenShift Route를 사용해야 합니까? Route Object를 사용하는 응용 프로그램이 이미 있는 경우 어떻게 합니까? Kubernetes ingress를 염두에 두고 작성된 애플리케이션을 배포하는 경우 어떻게 됩니까?

걱정하지마세요! Red Hat OpenShift 3.10 릴리스 이후로 Ingress Object는 Route Object와 함께 지원됩니다. Red Hat OpenShift 수신 컨트롤러 구현은 수신 객체를 감시하고 지정된 조건을 충족하기 위해 하나 이상의 경로를 생성하도록 설계되었습니다. 수신 객체를 변경하면 Red Hat OpenShift 수신 컨트롤러는 변경 사항을 동기화하고 생성된 경로 객체에 적용합니다. 그런 다음 내장된 HAProxy 로드 밸런서에서 선택합니다.

OpenShift에서 인그레스 개체 만들기

그것이 실제로 어떻게 작동하는지 봅시다. 먼저 워크스테이션 에서 단일 노드 로컬 OKD (Red Hat OpenShift를 지원하는 Kubernetes의 커뮤니티 배포) 클러스터 를 생성하기 위해 minishift 를 다운로드합니다.

$ minishift start --vm-driver=virtualbox --openshift-version=v3.10.0

OpenShift가 시작되고 실행되면 개발자/개발자로 로그인하고 새 프로젝트(네임스페이스)를 만들 수 있습니다.

$ oc login

$ oc new-project demo

이제 배포하고 나중에 인그레스 개체로 노출할 컨테이너 이미지가 필요합니다. Spring Boot에는 GitHub에서 사용할 수 있는 Spring PetClinic 이라는 샘플 Java 애플리케이션 이 있으며 여기에서 사용하기에 좋은 애플리케이션입니다. 그러나 Kubernetes에 배포하려면 Spring PetClinic 애플리케이션에 대한 컨테이너 이미지가 필요합니다. 다행히 Red Hat OpenShift에서는 애플리케이션의 소스 코드에서 컨테이너 이미지를 빌드하기 위한 소스-이미지 간 메커니즘이 내장되어 있기 때문에 매우 쉽습니다.

Red Hat OpenJDK 이미지를 Spring PetClinic의 기본 Java 이미지로 사용하기 위해 minishift로 가져옵니다.

$ oc create -f https://raw.githubusercontent.com/openshift/library/master/official/java/imagestreams/java-rhel7.json -n openshift --as=system:admin

Java 런타임을 사용하여 GitHub의 Spring PetClinic 소스 코드에서 컨테이너 이미지를 빌드하기 위해 빌드 개체를 만듭니다.

$ oc new-build java:8~https://github.com/spring-projects/spring-petclinic.git

# 빌드 로그 확인
$ oc logs -f bc/spring-petclinic

빌드가 완료되면 OpenShift 내장 이미지 레지스트리에서 Spring PetClinic 이미지를 볼 수 있습니다.

$ oc get is

NAME DOCKER REPO TAGS

spring-petclinic 172.30.1.1:5000/demo/spring-petclinic latest

이제 배포 및 서비스 개체를 생성하여 이미지를 배포할 수 있습니다.

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: spring-petclinic
  labels:
    app: spring-petclinic
spec:
  template:
    metadata:
      labels:
        app: spring-petclinic
    spec:
      containers:
      - name: spring-petclinic
        image: 172.30.1.1:5000/demo/spring-petclinic:latest
        ports:
        - containerPort: 8080
---

apiVersion: v1
kind: Service
metadata:
  name: spring-petclinic
spec:
  selector:
    app: spring-petclinic
  ports:
  - name: http
    protocol: TCP
    port: 8080
    targetPort: 8080

위의 YAML 정의를 파일에 저장한 다음 배포 및 서비스를 만듭니다.

$ oc create -f petclinic.yml

브라우저에서 Red Hat OpenShift 웹 콘솔에 로그인하면(힌트: minishift 콘솔 실행) Spring PetClinic 애플리케이션이 배포되고 실행 중임을 확인해야 합니다.

배포된 앱으로 외부 트래픽을 라우팅하기 위해 이제 애플리케이션에 대한 외부 액세스를 활성화하는 수신 개체를 만들 수 있습니다. 호스트 속성은 서비스에 대한 외부 액세스를 위해 로드 밸런서에 노출되어야 하는 URL을 지정하고 경로 속성은 컨텍스트 경로와 각 서비스 간의 매핑을 지정합니다. minishift에서 실행 중인 경우 일반 nip.io 와일드카드 DNS 서비스를 사용할 수 있습니다. 그렇지 않으면 Red Hat OpenShift 클러스터에 대해 구성된 호스트 이름과 일치하는지 확인하십시오.

apiVersion: extensions/v1beta1

kind: Ingress
metadata:
  name: spring-petclinic
spec:
  rules:
  - host: petclinic.192.168.99.100.nip.io
    http:
     paths:
     - path: /
       backend:
        serviceName: spring-petclinic
        servicePort: 8080

$ oc create -f ingress.yml

Ingress 개체가 생성되자마자 공개적으로 액세스 가능한 URL이 브라우저에서 Spring PetClinic 애플리케이션에 액세스할 수 있도록 하는 내장 로드 밸런서에 추가되었음을 알 수 있습니다.

프로젝트의 ingress 및 route object를 나열하면 service를 노출하기 위해 생성하고 수신 컨트롤러에 의해 동기화된 상태로 유지되는 ingress object에 대해 생성된 route object가 있음을 알 수 있습니다.

$ oc get ingress

NAME HOSTS ADDRESS PORTS
spring-petclinic petclinic.192.168.99.100.nip.io 80

$ oc get route

NAME HOST/PORT PATH SERVICES PORT
spring-petclinic-cbm6q petclinic.192.168.99.100.nip.io / spring-petclinic 8080

Ingress 또는 Route를 사용해야 합니까?

Ingress와 Route는 비슷하지만 성숙도와 기능에 차이가 있습니다. 여러 Kubernetes 배포판에 동시에 애플리케이션을 배포하려는 경우 Ingress가 좋은 옵션이 될 수 있지만 각 Kubernetes 배포판이 HTTP 및 TLS re-encryption와 같은 더 복잡한 라우팅 기능을 제공하는 구체적인 방법을 처리해야 합니다. 다른 모든 애플리케이션의 경우 Ingress가 필요한 기능을 제공하지 않는 시나리오가 발생할 수 있습니다. 다음 표에는 Kubernetes Ingress와 Red Hat OpenShift Routes 간의 차이점이 요약되어 있습니다.

특징	Ingress on OpenShift	Route on OpenShift
표준 Kubernetes 객체	X
서비스에 대한 외부 액세스	X	X
영구(고정) 세션	X	X
로드 밸런싱 전략(예: 라운드 로빈)	X	X
속도 제한 및 조절	X	X
IP 화이트리스트	X	X
향상된 보안을 위한 TLS 에지 종료	X	X
향상된 보안을 위한 TLS 재암호화		X
향상된 보안을 위한 TLS 패스스루		X
다중 가중치 백엔드(분할 트래픽)		X
생성된 패턴 기반 호스트 이름		X
와일드카드 도메인		X

결론

Red Hat OpenShift는 아직 Kubernetes에 없는 기능의 인큐베이터 역할을 할 수 있으며 업스트림 커뮤니티와 협력하여 이러한 기능을 Kubernetes에 다시 기여할 수 있습니다. Route 및 Ingress 개체는 이러한 업스트림 협업의 예이며 각각에 대한 규칙을 지정하는 방법은 다르지만 궁극적으로 동일한 기능을 달성하려고 하므로 외부 클라이언트가 정의된 규칙 집합에 따라 클러스터 서비스에 도달할 수 있습니다.

Red Hat OpenShift 사용자는 이러한 기능이 Kubernetes에 도입되면 이전과 같이 Kubernetes 객체로 전환하고 Red Hat OpenShift 플랫폼을 계속 사용할 수 있는 옵션이 있습니다. 그럼에도 불구하고 Ingress와 Route 간의 기능 세트 차이로 인해 여러 Kubernetes 배포에 동일한 객체를 배포해야 하는 경우가 아니라면 Route 객체는 Red Hat OpenShift에서 권장되는 접근 방식입니다.

릴리스 노트 에서 Red Hat OpenShift 3.10에서 사용할 수 있는 새로운 기능에 대해 자세히 알아볼 수 있습니다 .

저작자표시

Vision Factory

Kubernetes Ingress VS OpenShift Route

OpenShift에서 인그레스 개체 만들기

Ingress 또는 Route를 사용해야 합니까?

결론

티스토리툴바