1.3. 경로 구성

프로세스

1. 경로 정의를 생성하고 app-example-route.yaml 이라는 파일에 저장합니다.

   HTTP 헤더 지시문을 사용하여 생성된 경로의 YAML 정의

   apiVersion: route.openshift.io/v1
   kind: Route
   # ...
   spec:
     host: app.example.com
     tls:
       termination: edge
     to:
       kind: Service
       name: app-example
     httpHeaders:
       actions: 

   1

   
         response: 

   2

   
         - name: Content-Location 

   3

   
           action:
             type: Set 

   4

   
             set:
               value: /lang/en-us 

   5

   Copy to Clipboard Toggle word wrap

   1

   HTTP 헤더에서 수행할 작업 목록입니다.

   2

   변경할 헤더 유형입니다. 이 경우 응답 헤더입니다.

   3

   변경할 헤더의 이름입니다. 설정하거나 삭제할 수 있는 사용 가능한 헤더 목록은 HTTP 헤더 구성 을 참조하십시오.

   4

   헤더에서 수행되는 작업 유형입니다. 이 필드에는 Set 또는 Delete 값이 있을 수 있습니다.

   5

   HTTP 헤더를 설정할 때 값을 제공해야 합니다. 값은 해당 헤더에 사용 가능한 지시문 목록(예: DENY )의 문자열이거나 HAProxy의 동적 값 구문을 사용하여 해석되는 동적 값이 될 수 있습니다. 이 경우 값은 콘텐츠의 상대 위치로 설정됩니다.

2. 새로 생성된 경로 정의를 사용하여 기존 웹 애플리케이션에 대한 경로를 생성합니다.

   $ oc -n app-example create -f app-example-route.yaml

   Copy to Clipboard Toggle word wrap

1. 기본적으로 라우터는 5s마다 다시 로드되어 처음부터 포드 간에 분산 연결을 재설정합니다. 결과적으로 roundrobin 상태는 다시 로드해도 유지되지 않습니다. 이 알고리즘은 Pod에 거의 동일한 컴퓨팅 용량 및 스토리지 용량이 있는 경우 가장 잘 작동합니다. 예를 들어 CI/CD 파이프라인을 사용하므로 애플리케이션 또는 서비스에서 끝점을 지속적으로 변경한 경우 분산이 일관되지 않을 수 있습니다. 이 경우 다른 알고리즘을 사용하십시오.

2. 허용 목록의 IP 주소 및 CIDR 범위가 61를 초과하면 haproxy.config 파일에서 참조되는 별도의 파일에 작성됩니다. 이 파일은 /var/lib/haproxy/router/allowlists 폴더에 저장됩니다.

   참고

   주소가 허용 목록에 작성되도록 하려면 전체 CIDR 범위가 Ingress 컨트롤러 구성 파일에 나열되어 있는지 확인합니다. etcd 오브젝트 크기 제한은 경로 주석의 크기를 제한합니다. 이로 인해 허용 목록에 포함할 수 있는 최대 IP 주소 및 CIDR 범위에 대한 임계값이 생성됩니다.

프로세스

1. Ingress 컨트롤러가 워크로드로 IPv4/IPv6을 통해 트래픽을 제공하도록 하려면 ipFamilies 및 ipFamilyPolicy 필드를 설정하여 서비스 YAML 파일을 생성하거나 기존 서비스 YAML 파일을 수정할 수 있습니다. 예를 들면 다음과 같습니다.

   샘플 서비스 YAML 파일

   apiVersion: v1
   kind: Service
   metadata:
     creationTimestamp: yyyy-mm-ddT00:00:00Z
     labels:
       name: <service_name>
       manager: kubectl-create
       operation: Update
       time: yyyy-mm-ddT00:00:00Z
     name: <service_name>
     namespace: <namespace_name>
     resourceVersion: "<resource_version_number>"
     selfLink: "/api/v1/namespaces/<namespace_name>/services/<service_name>"
     uid: <uid_number>
   spec:
     clusterIP: 172.30.0.0/16
     clusterIPs: 

   1

   
     - 172.30.0.0/16
     - <second_IP_address>
     ipFamilies: 

   2

   
     - IPv4
     - IPv6
     ipFamilyPolicy: RequireDualStack 

   3

   
     ports:
     - port: 8080
       protocol: TCP
       targetport: 8080
     selector:
       name: <namespace_name>
     sessionAffinity: None
     type: ClusterIP
   status:
     loadbalancer: {}

   Copy to Clipboard Toggle word wrap

   1

   듀얼 스택 인스턴스에는 두 개의 서로 다른 clusterIPs가 제공됩니다.

   2

   단일 스택 인스턴스의 경우 IPv4 또는 IPv6을 입력합니다. 듀얼 스택 인스턴스의 경우 IPv4 및 IPv6 모두를 입력합니다.

   3

   단일 스택 인스턴스의 경우 SingleStack을 입력합니다. 듀얼 스택 인스턴스의 경우 RequireDualStack을 입력합니다.

   이러한 리소스는 해당 endpoints를 생성합니다. Ingress 컨트롤러는 이제 endpointslices를 감시합니다.

2. endpoints를 확인하려면 다음 명령을 입력합니다:

   $ oc get endpoints

   Copy to Clipboard Toggle word wrap

3. endpointslices를 확인하려면 다음 명령을 입력합니다.

   $ oc get endpointslices

   Copy to Clipboard Toggle word wrap