1.2. 클러스터 업데이트 작동 방식


다음 섹션에서는 OpenShift Container Platform(OCP) 업데이트 프로세스의 각 주요 측면을 자세히 설명합니다. 업데이트가 작동하는 방법에 대한 일반적인 개요는 OpenShift 업데이트 소개를 참조하십시오.

1.2.1. 클러스터 버전 연산자

클러스터 버전 운영자(CVO)는 OpenShift 컨테이너 플랫폼 업데이트 프로세스를 조율하고 원활하게 하는 주요 구성 요소입니다. 설치 및 표준 클러스터 운영 중에 CVO는 관리되는 클러스터 운영자의 매니페스트를 클러스터 내 리소스와 지속적으로 비교하고, 불일치 사항을 조정하여 이러한 리소스의 실제 상태가 원하는 상태와 일치하는지 확인합니다.

1.2.1.1. ClusterVersion 오브젝트

CVO(Cluster Version Operator)가 모니터링하는 리소스 중 하나는 ClusterVersion 리소스입니다.

관리자와 OpenShift 구성 요소는 ClusterVersion 객체를 통해 CVO와 통신하거나 상호 작용할 수 있습니다. 원하는 CVO 상태는 ClusterVersion 객체를 통해 선언되고 현재 CVO 상태는 객체의 상태에 반영됩니다.

참고

ClusterVersion 객체를 직접 수정하지 마세요. 대신 oc CLI나 웹 콘솔과 같은 인터페이스를 사용하여 업데이트 대상을 선언하세요.

CVO는 ClusterVersion 리소스의 spec 속성에 선언된 대상 상태와 클러스터를 지속적으로 조정합니다. 원하는 릴리스가 실제 릴리스와 다른 경우 해당 조정을 통해 클러스터가 업데이트됩니다.

가용성 데이터 업데이트

ClusterVersion 리소스에는 클러스터에서 사용할 수 있는 업데이트에 대한 정보도 포함되어 있습니다. 여기에는 클러스터에 적용되는 알려진 위험으로 인해 사용 가능하지만 권장되지 않는 업데이트가 포함됩니다. 이러한 업데이트는 조건부 업데이트라고 합니다. CVO가 ClusterVersion 리소스에서 사용 가능한 업데이트에 대한 정보를 어떻게 유지 관리하는지 알아보려면 "업데이트 가용성 평가" 섹션을 참조하세요.

  • 다음 명령을 사용하면 사용 가능한 모든 업데이트를 검사할 수 있습니다.

    $ oc adm upgrade --include-not-recommended
    Copy to Clipboard Toggle word wrap
    참고

    추가 --include-not-recommended 매개변수에는 클러스터에 적용되는 알려진 문제가 있는 업데이트가 포함됩니다.

    출력 예

    Cluster version is 4.13.40
    
    Upstream is unset, so the cluster will use an appropriate default.
    Channel: stable-4.14 (available channels: candidate-4.13, candidate-4.14, eus-4.14, fast-4.13, fast-4.14, stable-4.13, stable-4.14)
    
    Recommended updates:
    
      VERSION     IMAGE
      4.14.27     quay.io/openshift-release-dev/ocp-release@sha256:4d30b359aa6600a89ed49ce6a9a5fdab54092bcb821a25480fdfbc47e66af9ec
      4.14.26     quay.io/openshift-release-dev/ocp-release@sha256:4fe7d4ccf4d967a309f83118f1a380a656a733d7fcee1dbaf4d51752a6372890
      4.14.25     quay.io/openshift-release-dev/ocp-release@sha256:a0ef946ef8ae75aef726af1d9bbaad278559ad8cab2c1ed1088928a0087990b6
      4.14.24     quay.io/openshift-release-dev/ocp-release@sha256:0a34eac4b834e67f1bca94493c237e307be2c0eae7b8956d4d8ef1c0c462c7b0
      4.14.23     quay.io/openshift-release-dev/ocp-release@sha256:f8465817382128ec7c0bc676174bad0fb43204c353e49c146ddd83a5b3d58d92
      4.13.42     quay.io/openshift-release-dev/ocp-release@sha256:dcf5c3ad7384f8bee3c275da8f886b0bc9aea7611d166d695d0cf0fff40a0b55
      4.13.41     quay.io/openshift-release-dev/ocp-release@sha256:dbb8aa0cf53dc5ac663514e259ad2768d8c82fd1fe7181a4cfb484e3ffdbd3ba
    
    Updates with known issues:
    
      Version: 4.14.22
      Image: quay.io/openshift-release-dev/ocp-release@sha256:7093fa606debe63820671cc92a1384e14d0b70058d4b4719d666571e1fc62190
      Reason: MultipleReasons
      Message: Exposure to AzureRegistryImageMigrationUserProvisioned is unknown due to an evaluation failure: client-side throttling: only 18.061µs has elapsed since the last match call completed for this cluster condition backend; this cached cluster condition request has been queued for later execution
      In Azure clusters with the user-provisioned registry storage, the in-cluster image registry component may struggle to complete the cluster update. https://issues.redhat.com/browse/IR-468
    
      Incoming HTTP requests to services exposed by Routes may fail while routers reload their configuration, especially when made with Apache HTTPClient versions before 5.0. The problem is more likely to occur in clusters with higher number of Routes and corresponding endpoints. https://issues.redhat.com/browse/NE-1689
    
      Version: 4.14.21
      Image: quay.io/openshift-release-dev/ocp-release@sha256:6e3fba19a1453e61f8846c6b0ad3abf41436a3550092cbfd364ad4ce194582b7
      Reason: MultipleReasons
      Message: Exposure to AzureRegistryImageMigrationUserProvisioned is unknown due to an evaluation failure: client-side throttling: only 33.991µs has elapsed since the last match call completed for this cluster condition backend; this cached cluster condition request has been queued for later execution
      In Azure clusters with the user-provisioned registry storage, the in-cluster image registry component may struggle to complete the cluster update. https://issues.redhat.com/browse/IR-468
    
      Incoming HTTP requests to services exposed by Routes may fail while routers reload their configuration, especially when made with Apache HTTPClient versions before 5.0. The problem is more likely to occur in clusters with higher number of Routes and corresponding endpoints. https://issues.redhat.com/browse/NE-1689
    Copy to Clipboard Toggle word wrap

    oc adm upgrade 명령은 사용 가능한 업데이트에 대한 정보를 ClusterVersion 리소스에 쿼리하여 사람이 읽을 수 있는 형식으로 표시합니다.

  • CVO가 생성한 기본 가용성 데이터를 직접 검사하는 한 가지 방법은 다음 명령을 사용하여 ClusterVersion 리소스를 쿼리하는 것입니다.

    $ oc get clusterversion version -o json | jq '.status.availableUpdates'
    Copy to Clipboard Toggle word wrap

    출력 예

    [
      {
        "channels": [
          "candidate-4.11",
          "candidate-4.12",
          "fast-4.11",
          "fast-4.12"
        ],
        "image": "quay.io/openshift-release-dev/ocp-release@sha256:400267c7f4e61c6bfa0a59571467e8bd85c9188e442cbd820cc8263809be3775",
        "url": "https://access.redhat.com/errata/RHBA-2023:3213",
        "version": "4.11.41"
      },
      ...
    ]
    Copy to Clipboard Toggle word wrap

  • 비슷한 명령을 사용하여 조건부 업데이트를 확인할 수 있습니다.

    $ oc get clusterversion version -o json | jq '.status.conditionalUpdates'
    Copy to Clipboard Toggle word wrap

    출력 예

    [
      {
        "conditions": [
          {
            "lastTransitionTime": "2023-05-30T16:28:59Z",
            "message": "The 4.11.36 release only resolves an installation issue https://issues.redhat.com//browse/OCPBUGS-11663 , which does not affect already running clusters. 4.11.36 does not include fixes delivered in recent 4.11.z releases and therefore upgrading from these versions would cause fixed bugs to reappear. Red Hat does not recommend upgrading clusters to 4.11.36 version for this reason. https://access.redhat.com/solutions/7007136",
            "reason": "PatchesOlderRelease",
            "status": "False",
            "type": "Recommended"
          }
        ],
        "release": {
          "channels": [...],
          "image": "quay.io/openshift-release-dev/ocp-release@sha256:8c04176b771a62abd801fcda3e952633566c8b5ff177b93592e8e8d2d1f8471d",
          "url": "https://access.redhat.com/errata/RHBA-2023:1733",
          "version": "4.11.36"
        },
        "risks": [...]
      },
      ...
    ]
    Copy to Clipboard Toggle word wrap

1.2.1.2. 업데이트 가용성 평가

클러스터 버전 운영자(CVO)는 업데이트 가능성에 대한 최신 데이터를 얻기 위해 OpenShift 업데이트 서비스(OSUS)에 주기적으로 쿼리를 보냅니다. 이 데이터는 클러스터의 구독 채널을 기반으로 합니다. 그런 다음 CVO는 ClusterVersion 리소스의 availableUpdates 또는 conditionalUpdates 필드에 업데이트 권장 사항에 대한 정보를 저장합니다.

CVO는 업데이트 위험에 대한 조건부 업데이트를 주기적으로 확인합니다. 이러한 위험은 OSUS에서 제공하는 데이터를 통해 전달됩니다. 이 데이터에는 해당 버전으로 업데이트된 클러스터에 영향을 미칠 수 있는 알려진 문제에 대한 정보가 각 버전별로 포함되어 있습니다. 대부분의 위험은 특정 규모의 클러스터나 특정 클라우드 플랫폼에 배포된 클러스터 등 특정한 특성을 지닌 클러스터에 국한됩니다.

CVO는 각 조건부 업데이트에 대한 조건부 위험 정보에 대해 클러스터 특성을 지속적으로 평가합니다. CVO가 클러스터가 기준에 부합한다고 판단하면 CVO는 이 정보를 ClusterVersion 리소스의 conditionalUpdates 필드에 저장합니다. CVO가 클러스터가 업데이트 위험에 맞지 않거나 업데이트와 관련된 위험이 없다고 판단하는 경우, ClusterVersion 리소스의 availableUpdates 필드에 대상 버전을 저장합니다.

사용자 인터페이스(웹 콘솔 또는 OpenShift CLI( oc ))는 이 정보를 섹션별 제목으로 관리자에게 표시합니다. 업데이트 경로와 관련된 각 알려진 문제에는 해당 위험에 대한 추가 리소스에 대한 링크가 포함되어 있어 관리자가 업데이트에 대한 정보에 입각한 결정을 내릴 수 있습니다.

1.2.2. 릴리스 이미지

릴리스 이미지는 특정 OpenShift Container Platform(OCP) 버전을 제공하는 메커니즘입니다. 여기에는 릴리스 메타데이터, 릴리스 버전과 일치하는 클러스터 버전 운영자(CVO) 바이너리, 개별 OpenShift 클러스터 운영자를 배포하는 데 필요한 모든 매니페스트, 이 OpenShift 버전을 구성하는 모든 컨테이너 이미지에 대한 SHA 다이제스트 버전 참조 목록이 포함됩니다.

다음 명령을 실행하여 특정 릴리스 이미지의 내용을 검사할 수 있습니다.

$ oc adm release extract <release image>
Copy to Clipboard Toggle word wrap

출력 예

$ oc adm release extract quay.io/openshift-release-dev/ocp-release:4.12.6-x86_64
Extracted release payload from digest sha256:800d1e39d145664975a3bb7cbc6e674fbf78e3c45b5dde9ff2c5a11a8690c87b created at 2023-03-01T12:46:29Z

$ ls
0000_03_authorization-openshift_01_rolebindingrestriction.crd.yaml
0000_03_config-operator_01_proxy.crd.yaml
0000_03_marketplace-operator_01_operatorhub.crd.yaml
0000_03_marketplace-operator_02_operatorhub.cr.yaml
0000_03_quota-openshift_01_clusterresourcequota.crd.yaml 
1

...
0000_90_service-ca-operator_02_prometheusrolebinding.yaml 
2

0000_90_service-ca-operator_03_servicemonitor.yaml
0000_99_machine-api-operator_00_tombstones.yaml
image-references 
3

release-metadata
Copy to Clipboard Toggle word wrap

1
Runlevel 03에 적용될 ClusterResourceQuota CRD에 대한 매니페스트
2
Runlevel 90에 적용될 service-ca-operatorPrometheusRoleBinding 리소스에 대한 매니페스트
3
모든 필수 이미지에 대한 SHA 다이제스트 버전 참조 목록

1.2.3. 프로세스 워크플로 업데이트

다음 단계는 OpenShift Container Platform(OCP) 업데이트 프로세스의 자세한 워크플로를 나타냅니다.

  1. 대상 버전은 ClusterVersion 리소스의 spec.desiredUpdate.version 필드에 저장되며, 웹 콘솔이나 CLI를 통해 관리할 수 있습니다.
  2. 클러스터 버전 운영자(CVO)는 ClusterVersion 리소스의 desiredUpdate 가 현재 클러스터 버전과 다르다는 것을 감지합니다. CVO는 OpenShift 업데이트 서비스의 그래프 데이터를 사용하여 원하는 클러스터 버전을 릴리스 이미지에 대한 풀 사양으로 변환합니다.
  3. CVO는 릴리스 이미지의 무결성과 진위성을 검증합니다. Red Hat은 이미지 SHA 다이제스트를 고유하고 변경할 수 없는 릴리스 이미지 식별자로 사용하여 사전 정의된 위치에 게시된 릴리스 이미지에 대한 암호화된 서명된 진술을 게시합니다. CVO는 내장된 공개 키 목록을 활용하여 검사된 릴리스 이미지와 일치하는 진술의 존재와 서명을 검증합니다.
  4. CVO는 openshift-cluster-version 네임스페이스에 version-$version-$hash라는 이름의 작업을 생성합니다. 이 작업은 릴리스 이미지를 실행하는 컨테이너를 사용하므로 클러스터는 컨테이너 런타임을 통해 이미지를 다운로드합니다. 그런 다음 작업은 릴리스 이미지에서 매니페스트와 메타데이터를 추출하여 CVO에서 액세스할 수 있는 공유 볼륨으로 보냅니다.
  5. CVO는 추출된 매니페스트 및 메타데이터의 유효성을 검사합니다.
  6. CVO는 클러스터에서 문제 조건이 감지되지 않는지 확인하기 위해 몇 가지 전제 조건을 확인합니다. 특정 조건으로 인해 업데이트가 진행되지 않을 수 있습니다. 이러한 조건은 CVO 자체에서 결정하거나, 클러스터 운영자가 업데이트를 위해 문제가 있다고 생각하는 클러스터에 대한 세부 정보를 감지하여 보고합니다.
  7. CVO는 승인된 릴리스를 status.desired 에 기록하고 새 업데이트에 대한 status.history 항목을 만듭니다.
  8. CVO가 릴리스 이미지에서 매니페스트를 조정하기 시작합니다. 클러스터 연산자는 런레벨이라고 하는 별도의 단계로 업데이트되며, CVO는 런레벨에 있는 모든 연산자가 다음 레벨로 넘어가기 전에 업데이트를 완료하도록 보장합니다.
  9. CVO 자체에 대한 매니페스트는 프로세스 초기에 적용됩니다. CVO 배포가 적용되면 현재 CVO 포드가 중지되고 새 버전을 사용하는 CVO 포드가 시작됩니다. 새 CVO는 나머지 매니페스트를 조정합니다.
  10. 업데이트는 전체 제어 평면이 새 버전으로 업데이트될 때까지 진행됩니다. 개별 클러스터 운영자는 클러스터의 해당 도메인에서 업데이트 작업을 수행할 수 있으며, 작업을 수행하는 동안 Progressing=True 조건을 통해 상태를 보고합니다.
  11. MCO(Machine Config Operator) 매니페스트는 프로세스의 마지막에 적용됩니다. 업데이트된 MCO는 모든 노드의 시스템 구성과 운영 체제 업데이트를 시작합니다. 각 노드는 다시 작업 부하를 수용하기 전에 비워지고, 업데이트되고, 재부팅될 수 있습니다.

클러스터는 제어 평면 업데이트가 완료된 후, 일반적으로 모든 노드가 업데이트되기 전에 업데이트된 것으로 보고합니다. 업데이트 후 CVO는 모든 클러스터 리소스를 릴리스 이미지에서 제공된 상태와 일치하도록 유지 관리합니다.

1.2.4. 업데이트 중에 매니페스트가 적용되는 방식 이해

릴리스 이미지에 제공된 일부 매니페스트는 매니페스트 간의 종속성으로 인해 특정 순서로 적용해야 합니다. 예를 들어, CustomResourceDefinition 리소스는 일치하는 사용자 지정 리소스보다 먼저 생성되어야 합니다. 또한, 클러스터의 중단을 최소화하기 위해 개별 클러스터 운영자를 업데이트하는 데에는 논리적 순서가 있습니다. 클러스터 버전 운영자(CVO)는 실행 수준이라는 개념을 통해 이러한 논리적 순서를 구현합니다.

이러한 종속성은 릴리스 이미지의 매니페스트 파일 이름에 인코딩되어 있습니다.

0000_<runlevel>_<component>_<manifest-name>.yaml
Copy to Clipboard Toggle word wrap

예를 들면 다음과 같습니다.

0000_03_config-operator_01_proxy.crd.yaml
Copy to Clipboard Toggle word wrap

CVO는 매니페스트에 대한 종속성 그래프를 내부적으로 구축하며, CVO는 다음 규칙을 따릅니다.

  • 업데이트 중에는 낮은 Runlevel의 매니페스트가 높은 Runlevel의 매니페스트보다 먼저 적용됩니다.
  • 하나의 Runlevel 내에서 다양한 구성 요소에 대한 매니페스트를 병렬로 적용할 수 있습니다.
  • 하나의 Runlevel 내에서는 단일 구성 요소에 대한 매니페스트가 사전식 순서로 적용됩니다.

그런 다음 CVO는 생성된 종속성 그래프에 따라 매니페스트를 적용합니다.

참고

일부 리소스 유형의 경우 CVO는 매니페스트가 적용된 후 리소스를 모니터링하고 리소스가 안정적인 상태에 도달한 후에만 업데이트가 성공적으로 완료된 것으로 간주합니다. 이 상태에 도달하는 데는 시간이 걸릴 수 있습니다. 이는 ClusterOperator 리소스의 경우 특히 그렇습니다. CVO는 클러스터 운영자가 자신을 업데이트한 다음 해당 ClusterOperator 상태를 업데이트할 때까지 기다립니다.

CVO는 다음 Runlevel로 진행하기 전에 Runlevel의 모든 클러스터 운영자가 다음 조건을 충족할 때까지 기다립니다.

  • 클러스터 연산자에는 Available=True 조건이 있습니다.
  • 클러스터 연산자에는 Degraded=False 조건이 있습니다.
  • 클러스터 운영자는 ClusterOperator 리소스에서 원하는 버전을 달성했다고 선언합니다.

일부 작업은 완료하는 데 상당한 시간이 걸릴 수 있습니다. CVO는 후속 실행 레벨이 안전하게 진행될 수 있도록 작업이 완료될 때까지 기다립니다. 새로운 릴리스의 매니페스트를 처음에 조정하는 데는 총 60~120분이 걸릴 것으로 예상됩니다. 업데이트 기간에 영향을 미치는 요소에 대한 자세한 내용은 OpenShift Container Platform 업데이트 기간 이해를 참조하세요.

이전 예제 다이어그램에서 CVO는 Runlevel 20에서 모든 작업이 완료될 때까지 기다리고 있습니다. CVO는 Runlevel의 Operator에 모든 매니페스트를 적용했지만 kube-apiserver-operator ClusterOperator는 새 버전이 배포된 후 일부 작업을 수행합니다. kube-apiserver-operator ClusterOperator는 Progressing=True 조건을 통해 이 진행 상황을 선언하고 status.versions 에서 새 버전을 조정된 것으로 선언하지 않습니다. CVO는 ClusterOperator가 허용 가능한 상태를 보고할 때까지 기다린 다음 Runlevel 25에서 매니페스트 조정을 시작합니다.

1.2.5. Machine Config Operator가 노드를 업데이트하는 방법 이해

MCO(Machine Config Operator)는 각 제어 평면 노드와 컴퓨팅 노드에 새로운 머신 구성을 적용합니다. 머신 구성 업데이트 동안 제어 플레인 노드와 컴퓨트 노드는 자체 머신 구성 풀로 구성되며, 머신 풀은 병렬로 업데이트됩니다. 기본값이 1.spec.maxUnavailable 매개변수는 머신 구성 풀에서 동시에 업데이트 프로세스를 거칠 수 있는 노드 수를 결정합니다.

주의

OpenShift Container Platform의 모든 머신 구성 풀에 대한 maxUnavailable 의 기본 설정은 1 입니다. 이 값은 변경하지 말고 한 번에 하나의 제어 평면 노드만 업데이트하는 것이 좋습니다. 제어 평면 풀의 경우 이 값을 3 으로 변경하지 마세요.

머신 구성 업데이트 프로세스가 시작되면 MCO는 풀에서 현재 사용할 수 없는 노드의 양을 확인합니다. 사용할 수 없는 노드가 .spec.maxUnavailable 값보다 적으면 MCO는 풀에서 사용 가능한 노드에 대해 다음과 같은 일련의 작업을 시작합니다.

  1. 노드를 봉쇄하고 배수합니다.

    참고

    노드가 격리되면 해당 노드에 작업 부하를 예약할 수 없습니다.

  2. 노드의 시스템 구성 및 운영 체제(OS)를 업데이트합니다.
  3. 노드를 재부팅하세요
  4. 노드를 차단 해제합니다

이 프로세스를 거치는 노드는 격리가 해제되고 작업 부하가 다시 예약될 때까지 사용할 수 없습니다. MCO는 사용할 수 없는 노드 수가 .spec.maxUnavailable 값과 같아질 때까지 노드 업데이트를 시작합니다.

노드가 업데이트를 완료하고 사용 가능해지면 머신 구성 풀에서 사용할 수 없는 노드의 수는 다시 .spec.maxUnavailable 보다 적어집니다. 업데이트가 필요한 노드가 남아 있는 경우 MCO는 .spec.maxUnavailable 한도에 다시 도달할 때까지 노드에서 업데이트 프로세스를 시작합니다. 이 프로세스는 각 제어 평면 노드와 컴퓨팅 노드가 업데이트될 때까지 반복됩니다.

다음 예제 워크플로는 5개의 노드가 있는 머신 구성 풀에서 이 프로세스가 어떻게 발생하는지 설명합니다. 여기서 .spec.maxUnavailable 은 3이고 모든 노드가 처음에 사용 가능합니다.

  1. MCO는 노드 1, 2, 3을 봉쇄하고 배수를 시작합니다.
  2. 노드 2의 배수가 완료되고 재부팅되어 다시 사용 가능해집니다. MCO가 노드 4를 봉쇄하고 배수를 시작합니다.
  3. 노드 1의 드레이닝이 완료되고 재부팅되어 다시 사용 가능해집니다. MCO가 노드 5를 봉쇄하고 배수를 시작합니다.
  4. 노드 3의 배수가 완료되고 재부팅되어 다시 사용 가능해집니다.
  5. 노드 5의 배수가 완료되고 재부팅되어 다시 사용 가능해집니다.
  6. 노드 4의 배수가 완료되고 재부팅되어 다시 사용 가능해집니다.

각 노드의 업데이트 프로세스는 다른 노드와 독립적이므로 위의 예에서 일부 노드는 MCO에서 차단된 순서에 관계없이 업데이트를 완료합니다.

다음 명령을 실행하여 머신 구성 업데이트 상태를 확인할 수 있습니다.

$ oc get mcp
Copy to Clipboard Toggle word wrap

출력 예

NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master       rendered-master-acd1358917e9f98cbdb599aea622d78b       True      False      False      3              3                   3                     0                      22h
worker       rendered-worker-1d871ac76e1951d32b2fe92369879826       False     True       False      2              1                   1                     0                      22h
Copy to Clipboard Toggle word wrap

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat