단일 Cryostat 클러스터에 여러 RHOSO 환경 배포

1. 개발 환경
2. 스테이징 환경
3. 환경 테스트

1. RHOSO 환경의 최소 네트워크 요구 사항을 검토합니다. RHOSO 네트워크 요구 사항에 대한 자세한 내용은 Cryo stat 네트워크 요구 사항 및 배포 계획에서 네트워크 계획을 참조하십시오.
2. 동일한 Cryostat 클러스터에서 여러 RHOSO 환경을 지원하도록 네트워크 토폴로지를 계획하고 각 네임스페이스에 대해 RHOSO 네트워크를 계획합니다.
3. RHOSO-dedicated NIC가 각 네임스페이스에 하나씩 있는 모든 Cryostat 작업자 노드에 있는지 확인하여 RHOSO 환경 간의 분리를 강화합니다. 이러한 인터페이스는 VLAN을 사용하여 추가 네트워크 격리를 수행합니다.
4. 네임스페이스 인터페이스와 해당 네임스페이스의 컴퓨팅 노드 간 연결이 있는지 확인합니다.
5. 각 네임스페이스의 VLAN ID와 서브넷이 겹치지 않는지 확인합니다.
6. 각 네임스페이스에 대한 각 RHOSO 환경에 대한 네트워크를 계획합니다. 각 네임스페이스에는 모든 네트워크에 대한 고유한 네트워크 IP 주소가 있어야 합니다. 네임스페이스 간 IP 주소와 범위를 겹치지 마십시오. 필요한 네트워크 값에 대한 자세한 내용은 OpenShift에 Red Hat OpenStack Services 배포 의 기본 Red Hat OpenStack Services의 "기본 RHOSO 네트워크 " 표를 참조하십시오.

프로세스

1. 배포된 RHOSO 환경에 대한 openstack 프로젝트를 생성합니다.

   $ oc new-project openstack

2. OpenStack Operator가 권한 있는 Pod 생성을 활성화하도록 openstack 네임스페이스에 레이블이 지정되어 있는지 확인합니다.

   $ oc get namespace openstack -ojsonpath='{.metadata.labels}' | jq
   {
     "kubernetes.io/metadata.name": "openstack",
     "pod-security.kubernetes.io/enforce": "privileged",
     "security.openshift.io/scc.podSecurityLabelSync": "false"
   }

   SCC(보안 컨텍스트 제약 조건)가 "권한"이 아닌 경우 다음 명령을 사용하여 변경합니다.

   $ oc label ns openstack security.openshift.io/scc.podSecurityLabelSync=false --overwrite
   $ oc label ns openstack pod-security.kubernetes.io/enforce=privileged --overwrite

3. 선택 사항: openstack 네임스페이스에서 명령을 실행할 때 네임스페이스를 지정할 필요가 없도록 하려면 default 네임스페이스를 openstack 으로 설정합니다.

   $ oc project openstack

프로세스

1. 워크스테이션에 Secret CR을 생성합니다(예: openstack_service_secret.yaml ).

2. openstack_service_secret.yaml 에 다음 초기 구성을 추가합니다.

   apiVersion: v1
   data:
     AdminPassword: <base64_password>
     AodhPassword: <base64_password>
     BarbicanPassword: <base64_password>
     BarbicanSimpleCryptoKEK: <base64_fernet_key>
     CeilometerPassword: <base64_password>
     CinderPassword: <base64_password>
     DbRootPassword: <base64_password>
     DesignatePassword: <base64_password>
     GlancePassword: <base64_password>
     HeatAuthEncryptionKey: <base64_password>
     HeatPassword: <base64_password>
     IronicInspectorPassword: <base64_password>
     IronicPassword: <base64_password>
     ManilaPassword: <base64_password>
     MetadataSecret: <base64_password>
     NeutronPassword: <base64_password>
     NovaPassword: <base64_password>
     OctaviaPassword: <base64_password>
     PlacementPassword: <base64_password>
     SwiftPassword: <base64_password>
   kind: Secret
   metadata:
     name: osp-secret
     namespace: openstack
   type: Opaque

   • & lt;base64_password& gt;를 base64로 인코딩된 32자 키로 바꿉니다.

     참고

     HeatAuthEncryptionKey 암호는 오케스트레이션 서비스(heat) 암호화의 32자 키여야 합니다. 다른 모든 서비스의 암호 길이를 늘리면 HeatAuthEncryptionKey 암호가 32인지 확인하십시오.

     다음 명령을 사용하여 base64로 인코딩된 암호를 수동으로 생성할 수 있습니다.

     $ echo -n <password> | base64

     또는 Linux 워크스테이션을 사용하고 cat 과 같은 Bash 명령을 사용하여 Secret CR을 생성하는 경우 < base64_password >를 다음 명령으로 교체하여 각 서비스에 대해 임의의 암호를 자동으로 생성할 수 있습니다.

     $(tr -dc 'A-Za-z0-9' < /dev/urandom | head -c 32 | base64)

   • &lt ;base64_fernet_key >를 base64로 인코딩된 fernet 키로 바꿉니다. 다음 명령을 사용하여 수동으로 생성할 수 있습니다.

     $(python3 -c "from cryptography.fernet import Fernet; print(Fernet.generate_key().decode('UTF-8'))" | base64)

3. 클러스터에 Secret CR을 생성합니다.

   $ oc create -f openstack_service_secret.yaml -n openstack

4. Secret CR이 생성되었는지 확인합니다.

   $ oc describe secret osp-secret -n openstack

프로세스

1. 워크스테이션에 netconfig_osp_ns_1.yaml 이라는 파일을 만듭니다.

2. netconfig_osp_ns_1.yaml 에 다음 구성을 추가하여 NetConfig CR을 생성합니다.

   apiVersion: network.openstack.org/v1beta1
   kind: NetConfig
   metadata:
     name: openstacknetconfig
     namespace: osp_ns_1

3. netconfig_osp_ns_1.yaml 파일에서 각 데이터 플레인 네트워크의 토폴로지를 정의합니다. 다음 예제에서는 데이터 플레인에 대한 격리된 네트워크를 생성합니다.

   spec:
     networks:
     - name: CtlPlane
       dnsDomain: ctlplane_1.example.com
       subnets:
       - name: subnet1
         allocationRanges:
         - end: 192.168.122.120
           start: 192.168.122.100
         - end: 192.168.122.200
           start: 192.168.122.150
         cidr: 192.168.122.0/24
         gateway: 192.168.122.1
     - name: InternalApi
       dnsDomain: internalapi_1.example.com
       subnets:
       - name: subnet1
         allocationRanges:
         - end: 172.17.0.250
           start: 172.17.0.100
         excludeAddresses:
         - 172.17.0.10
         - 172.17.0.12
         cidr: 172.17.0.0/24
         vlan: 20
     - name: External
       dnsDomain: external_1.example.com
       subnets:
       - name: subnet1
         allocationRanges:
         - end: 10.0.0.250
           start: 10.0.0.100
         cidr: 10.0.0.0/24
         gateway: 10.0.0.1
     - name: Storage
       dnsDomain: storage_1.example.com
       subnets:
       - name: subnet1
         allocationRanges:
         - end: 172.18.0.250
           start: 172.18.0.100
         cidr: 172.18.0.0/24
         vlan: 21
     - name: Tenant
       dnsDomain: tenant_1.example.com
       subnets:
       - name: subnet1
         allocationRanges:
         - end: 172.19.0.250
           start: 172.19.0.100
         cidr: 172.19.0.0/24
         vlan: 22

   • spec.networks.name: 네트워크의 이름입니다(예: CtlPlane ).
   • spec.networks.subnets: IPv4 서브넷 사양입니다.
   • spec.networks.subnets.name: 서브넷의 이름입니다(예: subnet1 ).
   • spec.networks.subnets.allocationRanges: NetConfig allocationRange. allocationRange 는 MetalLB IPAddressPool 범위 및 IP 주소 풀 범위와 겹치지 않아야 합니다.
   • spec.networks.subnets.excludeAddresses: 데이터 플레인 노드에서 사용해서는 안 되는 할당 범위의 IP 주소 선택적 목록입니다.
   • spec.networks.subnets.vlan: 네트워크 VLAN입니다. 기본 RHOSO 네트워크에 대한 자세한 내용은 OpenShift 네트워크의 기본 Red Hat OpenStack Services 를 참조하십시오.
4. netconfig_osp_ns_1.yaml 정의 파일을 저장합니다.

5. 데이터 플레인 네트워크를 생성합니다.

   $ oc create -f netconfig_osp_ns_1.yaml -n openstack

6. 데이터 플레인 네트워크가 생성되었는지 확인하려면 openstacknetconfig 리소스를 확인합니다.

   $ oc get netconfig/openstacknetconfig -n openstack

   오류가 표시되면 기본 network-attach-definition 및 노드 네트워크 구성 정책을 확인합니다.

   $ oc get network-attachment-definitions -n openstack
   $ oc get nncp

프로세스

1. OpenShift에 Red Hat OpenStack Services 배포의 컨트롤 플레인 생성 절차에 따라 osp_ns_1 네임스페이스에 대한 OpenStackControlPlane CR을 생성합니다.

2. 각 서비스의 로드 밸런서 구성을 찾아 해당 네임스페이스의 네트워크로 업데이트합니다.

     <service>:
       ...
           override:
             service:
               internal:
                 metadata:
                   annotations:
                     metallb.universe.tf/address-pool: internalapi_1
                     metallb.universe.tf/allow-shared-ip: internalapi_1
                     metallb.universe.tf/loadBalancerIPs: 172.17.0.80
                 spec:
                   type: LoadBalancer

   • MetalLB.universe.tf/address-pool: 서비스를 로드 밸런싱할 IP 주소를 할당하기 위한 IpAddressPool 입니다.

   • MetalLB.universe.tf/allow-shared-ip: 로드 밸런싱을 위해 에서 공유 IP 주소를 사용하는 IpAddressPool 입니다.

     참고

     rabbitmq의 여러 인스턴스와 같이 동일한 포트를 사용하는 서비스와 VIP를 공유할 수 없습니다.

   • MetalLB.universe.tf/loadBalancerIPs: 서비스 로드 밸런싱 시 사용할 IpAddressPool 범위에서 특정 VIP를 할당합니다.

3. 네임스페이스의 전용 인터페이스에 대응하도록 datacentre 네트워크의 nicMappings 를 구성하여 ovn 서비스의 NIC 매핑을 업데이트하여 네임스페이스의 OVNController 리소스가 다른 네임스페이스와 분리되었는지 확인합니다.

   ...
       ovn:
         enabled: true
         template:
           ovnController:
             nicMappings:
               datacentre: ospbr_1
           ovnDBCluster:
             ovndbcluster-nb:

4. 컨트롤 플레인을 업데이트합니다.

   $ oc apply -f osp_ns_1_control_plane.yaml -n openstack

5. Cryostat가 OpenStackControlPlane CR과 관련된 리소스를 생성할 때까지 기다립니다. 다음 명령을 실행하여 상태를 확인합니다.

   $ oc get openstackcontrolplane -n osp_ns_1
   NAME 						    STATUS 	  MESSAGE
   control-plane-ns-1 	Unknown 	Setup started

   상태가 "Setup complete"인 경우 OpenStackControlPlane 리소스가 생성됩니다.

   작은 정보

   get 명령의 끝에 -w 옵션을 추가하여 배포 진행 상황을 추적합니다.

6. 서비스 pod가 올바른 작업자 노드에서 실행 중인지 확인합니다.

프로세스

1. OpenShift에 Red Hat OpenStack Services 배포의 데이터 플레인 절차 생성 절차에 따라 osp_ns_1 네임스페이스에 대한 OpenStackDataPlaneNodeSet CR을 생성합니다.

2. nodes 섹션을 찾아 노드가 속한 네임스페이스를 나타내는 각 노드의 고유한 이름으로 hostName 및 ansibleVars.fqdn_internal_api 필드를 업데이트합니다.

     nodes:
       edpm-compute-0:
         hostName: edpm_1-compute-0
         networks:
         - name: ctlplane
           subnetName: subnet1
           defaultRoute: true
           fixedIP: 192.168.122.100
         - name: internalapi
           subnetName: subnet1
           fixedIP: 172.17.0.100
         - name: storage
           subnetName: subnet1
           fixedIP: 172.18.0.100
         - name: tenant
           subnetName: subnet1
           fixedIP: 172.19.0.100
         ansible:
           ansibleHost: 192.168.122.100
           ansibleUser: cloud-admin
           ansibleVars:
             fqdn_internal_api: edpm_1-compute-0.example.com

3. 네임스페이스에 정의된 각 노드에 대해 정의된 네트워크의 IP 주소를 업데이트합니다.

     nodes:
       edpm-compute-0:
         ...
         networks:
         - name: ctlplane
           subnetName: subnet1
           defaultRoute: true
           fixedIP: 192.168.122.100
         - name: internalapi
           subnetName: subnet1
           fixedIP: 172.17.0.100
         - name: storage
           subnetName: subnet1
           fixedIP: 172.18.0.100
         - name: tenant
           subnetName: subnet1
           fixedIP: 172.19.0.100
         ansible:
           ansibleHost: 192.168.122.100
           ...

   • fixedIP: osp_ns_1 네임스페이스의 네트워크의 IP 주소로 설정합니다.
4. 업데이트된 OpenStackDataPlaneNodeSet CR 정의 파일을 저장합니다.

5. 업데이트된 OpenStackDataPlaneNodeSet CR 구성을 적용합니다.

   $ oc apply -f osp_ns_1_data_plane.yaml

6. 상태가 SetupReady:인지 확인하여 데이터 플레인 리소스가 업데이트되었는지 확인합니다.

   $ oc wait openstackdataplanenodeset data-plane-ns-1 --for condition=SetupReady --timeout=10m

   상태가 SetupReady 이면 명령에서 condition met 메시지를 반환하고, 그렇지 않으면 시간 초과 오류가 반환됩니다.

7. 워크스테이션에 파일을 생성하여 새 OpenStackDataPlaneDeployment CR을 정의합니다.

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
     name: <node_set_deployment_name>

   • & lt;node_set_deployment_name >을 OpenStackDataPlaneDeployment CR 이름으로 바꿉니다. 이름은 고유해야 하며 소문자 영숫자( 하이 프린) 또는 . (period)로 구성되어야 하며 영숫자 문자로 시작하고 끝나야 합니다.
   작은 정보

   수정된 노드 세트의 목적을 나타내는 정의 파일과 OpenStackDataPlaneDeployment CR에 고유하고 설명이 포함된 이름을 지정합니다.

8. 수정한 OpenStackDataPlaneNodeSet CR을 추가합니다.

   spec:
     nodeSets:
       - <nodeSet_name>

9. OpenStackDataPlaneDeployment CR 배포 파일을 저장합니다.

10. 수정된 OpenStackDataPlaneNodeSet CR을 배포합니다.

    $ oc create -f osp_ns_1_data_plane_deploy.yaml -n openstack

    배포가 실행되는 동안 Ansible 로그를 볼 수 있습니다.

    $ oc get pod -l app=openstackansibleee -w
    $ oc logs -l app=openstackansibleee -f --max-log-requests 10

    oc logs 명령에서 다음 오류와 유사한 오류를 반환하는 경우 --max-log-requests 값을 늘립니다.

    error: you are attempting to follow 19 log streams, but maximum allowed concurrency is 10, use --max-log-requests to increase the limit

11. 수정된 OpenStackDataPlaneNodeSet CR이 배포되었는지 확인합니다.

    $ oc get openstackdataplanedeployment -n openstack
    NAME             	STATUS   MESSAGE
    data-plane-ns-1     True     Setup Complete
    
    
    $ oc get openstackdataplanenodeset -n openstack
    NAME             	STATUS   MESSAGE
    data-plane-ns-1     True     NodeSet Ready

    상태가 데이터 플레인이 배포되지 않았음을 나타내는 경우 배포 문제를 해결합니다. 자세한 내용은 OpenShift에 Red Hat OpenStack Services 배포 가이드의 데이터 플레인 생성 및 배포 문제 해결을 참조하십시오.