OpenShift 샌드박스 컨테이너 릴리스 노트

OpenShift Sandboxed Containers 1.5

OpenShift Container Platform의 경우

Red Hat Customer Content Services

초록

릴리스 노트에는 새로운 기능 및 개선 사항, 주요 기술 변경 사항, 이전 버전의 주요 수정 사항 및 일반 가용성에 따라 알려진 버그가 요약되어 있습니다.

머리말

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 이러한 변경 사항은 가능한 한 점진적으로 업데이트되고 있습니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

1장. 소개

2장. OpenShift 샌드박스 컨테이너 1.5 릴리스 노트

2.1. 릴리스 정보

이 릴리스 노트에서는 OpenShift Container Platform 4.15와 함께 OpenShift 샌드박스 컨테이너 1.5의 개발을 추적합니다.

OpenShift Container Platform은 FIPS용으로 설계되었습니다. FIPS 모드에서 부팅된 RHEL(Red Hat Enterprise Linux CoreOS) 또는 RHCOS(Red Hat Enterprise Linux CoreOS)를 실행하는 경우 OpenShift Container Platform 코어 구성 요소는 x86_64,ppc64le, s390x 아키텍처에서만 FIPS 140-2/140-3 Validation에 대해 NIST에 제출된 RHEL 암호화 라이브러리를 사용합니다.

NIST 검증 프로그램에 대한 자세한 내용은 암호화 모듈 유효성 검사 프로그램을 참조하십시오. 검증을 위해 제출된 개별 RHEL 암호화 라이브러리의 최신 NIST 상태는 규정 준수 활동 및 정부 표준을 참조하십시오.

2.2. 새로운 기능 및 개선 사항

2.2.1. AWS 및 Azure에 대한 유연한 Pod VM 인스턴스 크기

OpenShift 샌드박스 컨테이너 1.5에서 Pod VM의 인스턴스 크기를 지정할 수 있습니다. AWS의 PODVM_INSTANCE_TYPES 필드를 사용하거나 peer-pods-cm ConfigMap CR에서 Azure의 AZURE_INSTANCE_SIZES 를 사용할 수 있습니다. 자세한 내용은 웹 콘솔 을 사용하여 AWS의 피어 Pod ConfigMap 생성 및 웹 콘솔을 사용하여 Azure용 피어 Pod ConfigMap 생성을 참조하십시오.

2.2.2. AWS 및 Azure에서 자동 Pod VM 이미지 생성

OpenShift 샌드박스 컨테이너 1.5에서 peer-pods-secretpeer-pods-cm 오브젝트가 존재하고 peer-pods-cmAZURE_IMAGE_ID 또는 PODVM_AMI_ID 변수가 없거나 변수의 값이 비어 있으면 Pod VM 이미지가 자동으로 생성됩니다. 절차에 대한 자세한 내용은 웹 콘솔에서 KataConfig 사용자 지정 리소스 생성을참조하십시오.

2.2.3. 관리자에게 카타 노드 설치, 제거 및 업데이트 작업에 대한 보다 자세한 정보 제공

kata Nodes 라는 새 필드가 도입되어 사용자에게 카타 작업을 수행하는 노드 상태에 대한 보다 자세한 보기를 제공합니다. 기존 Is In Progress 부울 상태 필드가 더 많은 정보 진행 중 상태로 교체되었습니다.

자세한 내용은 전환 설치 및 제거를 참조하십시오.

2.2.4. IBM Z 및 IBM(R) LinuxONE에서 OpenShift 샌드박스 컨테이너에 대한 피어 Pod 지원 (기술 프리뷰)

사용자는 IBM Z 및 IBM® LinuxONE(390x 아키텍처)에서 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너 워크로드를 배포할 수 있습니다. 이를 통해 사용자는 중첩된 가상화의 필요성을 우회할 수 있습니다. 이 기능은 기술 프리뷰에 있으며 완전히 지원되지 않습니다. 자세한 내용은 피어 Pod를 사용하여 OpenShift 샌드박스 컨테이너 워크로드 배포를 참조하십시오.

2.3. 버그 수정

  • OpenShift 샌드박스 컨테이너 1.5.0 ~ 1.5.2에서는 사용자가 피어 Pod를 생성할 때 Go 1.21.1에서 네트워킹 기능 동작이 변경되어 "호스트 기본 인터페이스 식별 실패" 오류가 있는 ContainerCreating 상태로 남아 있었습니다. 이 문제는 OpenShift 샌드박스 컨테이너 1.5.3에서 해결되었습니다. (KATA-2847)
  • 이전 버전에서는 설치 중에 KataConfig CR 삭제를 시작하면 OpenShift 샌드박스 컨테이너 Operator가 두 프로세스를 완료하지 않고 동시에 삭제 및 설치를 시도했습니다. 이번 릴리스에서는 Operator에서 설치가 완료된 후 삭제를 직렬화합니다. (KATA-1851)
  • 이전에는 사용자가 특별히 레이블이 지정된 노드로 배포된 kata 지원 클러스터를 업데이트할 수 없었습니다. 노드 레이블 변경으로 인해 배포 변경 사항이 트리거되지 않았습니다. 사용자는 기존 kataConfig CR을 삭제하고 업데이트된 라벨을 사용하여 새 kataConfig CR을 생성해야 했습니다. 이전 릴리스(릴리스 1.4)부터 노드 레이블을 업데이트하면 배포 변경이 자동으로 트리거됩니다. (KATA-1928)
  • 이전 버전에서는 QEMU에서 virtiofsd 를 탐지하지 않으면 QEMU에서 kata 워크로드가 삭제될 때마다 시스템 저널에 오류를 기록했습니다. 이번 릴리스에서는 virtiofsd 를 중지하기 전에 kata 런타임에서 QEMU를 중지합니다. 이 수정은 OpenShift Container Platform 4.13 및 4.14에서만 사용할 수 있습니다. (KATA-2133)
  • 이전에는 KataConfig CR에서 피어 Pod를 활성화한 다음 설치 후 CR을 검사하면 kata-remote 런타임 클래스가 status.runtimeClass 필드에 표시되지 않았습니다. 이 문제는 OpenShift 샌드박스 컨테이너 1.5.0에서 해결되었습니다. (KATA-2164)
  • 이전 버전에서는 peer-pod VM이 실행되는 동안 peerpodconfig-ctrl-caa-daemon Pod를 다시 시작하면 동일한 피어 Pod를 나타내는 여러 VM이 생성될 수 있었습니다. 중복 인스턴스는 클라우드 공급자 콘솔 또는 CLI에서 인스턴스를 수동으로 삭제하지 않는 한 원래 피어 Pod가 계속 실행되는 동안 존재합니다. 이번 업데이트를 통해 peerpodconfig-ctrl-caa-daemon Pod를 다시 시작한 후 새 peer-pod VM이 생성되고 이전 인스턴스가 즉시 삭제됩니다. (KATA-2519)
  • 이전에는 사용자가 AWS 또는 Azure에서 실행되는 피어 Pod VM의 인스턴스 메타데이터를 요청하면 AWS 또는 Azure 인스턴스 메타데이터 서비스에서 Pod 대신 작업자 노드의 메타데이터를 반환했습니다. 릴리스 1.5.1에 대한 업데이트를 통해 AWS 또는 Azure 인스턴스 메타데이터 서비스는 Pod의 메타데이터를 예상대로 반환합니다. (KATA-2583)

2.4. 확인된 문제

  • OpenShift Container Platform 클러스터의 hostPath 볼륨에서 마운트된 파일 또는 디렉터리에 액세스할 때 SELinux 거부를 수신할 수 있습니다. 권한 있는 샌드박스 컨테이너가 SELinux 검사를 비활성화하지 않기 때문에 권한 있는 샌드박스 컨테이너를 실행하는 경우에도 이러한 거부가 발생할 수 있습니다.

    호스트의 SELinux 정책에 따라 기본적으로 샌드박스 워크로드에서 호스트 파일 시스템을 완전히 격리할 수 있습니다. 또한 virtiofsd 데몬 또는 QEMU의 잠재적인 보안 결함에 대해 더 강력한 보호 기능을 제공합니다.

    마운트된 파일 또는 디렉터리에 호스트에 특정 SELinux 요구 사항이 없는 경우 로컬 영구 볼륨을 대안으로 사용할 수 있습니다. 컨테이너 런타임의 SELinux 정책에 따라 파일이 자동으로 container_file_t 로 레이블이 다시 지정됩니다. 로컬 볼륨을 사용한 영구 스토리지를 참조하십시오.

    마운트된 파일 또는 디렉터리에 호스트의 특정 SELinux 레이블이 있을 것으로 예상되는 경우 자동 레이블은 옵션이 아닙니다. 대신 virtiofsd 데몬이 이러한 특정 라벨에 액세스할 수 있도록 호스트에서 사용자 지정 SELinux 규칙을 설정할 수 있습니다. (KATA-469)

  • 일부 OpenShift 샌드박스 컨테이너 Operator Pod는 컨테이너 CPU 리소스 제한을 사용하여 Pod에 사용 가능한 CPU 수를 늘립니다. 이러한 Pod는 요청된 것보다 적은 CPU를 수신할 수 있습니다. 컨테이너 내에서 기능을 사용할 수 있는 경우 oc rsh <pod >를 사용하여 Pod에 액세스하고 lscpu 명령을 실행하여 CPU 리소스 문제를 진단할 수 있습니다.

    $ lscpu

    출력 예

    CPU(s):                          16
    On-line CPU(s) list:             0-12,14,15
    Off-line CPU(s) list:            13

    오프라인 CPU 목록은 실행에서 실행으로 예기치 않게 변경될 수 있습니다.

    이 문제를 해결하려면 Pod 주석을 사용하여 CPU 제한을 설정하지 않고 추가 CPU를 요청할 수 있습니다. 프로세서 할당 방법이 다르기 때문에 Pod 주석을 사용하는 CPU 요청은 이 문제의 영향을 받지 않습니다. CPU 제한을 설정하지 않고 Pod의 메타데이터에 다음 주석을 추가해야 합니다.

    metadata:
      annotations:
        io.katacontainers.config.hypervisor.default_vcpus: "16"

    (KATA-1376)

  • 컨테이너의 보안 컨텍스트에서 SELinux MCS(Multi-Category Security) 레이블을 설정하면 Pod가 시작되지 않고 Pod 로그에 다음 오류가 표시됩니다.

    Error: CreateContainer failed: EACCES: Permission denied: unknown

    샌드박스 컨테이너가 생성될 때 런타임은 컨테이너의 보안 컨텍스트에 액세스할 수 없습니다. 즉 virtiofsd 는 적절한 SELinux 레이블로 실행되지 않으며 컨테이너의 호스트 파일에 액세스할 수 없습니다. 결과적으로 MCS 레이블을 사용하여 컨테이너별로 샌드박스 컨테이너의 파일을 격리할 수 없습니다. 즉, 모든 컨테이너가 샌드박스 컨테이너 내의 모든 파일에 액세스할 수 있습니다. 현재 이 문제에 대한 해결방법이 없습니다.

    (KATA-1875)

  • OpenShift 샌드박스 컨테이너에 대한 FIPS 컴플라이언스는 kata 런타임 클래스에만 적용됩니다. 새로운 피어 Pod 런타임 클래스 kata-remote 는 아직 완전히 지원되지 않으며 FIPS 컴플라이언스를 위해 테스트되지 않았습니다. (KATA-2166)
  • --announce-submount s 또는 --thread-pool-size 가 포함된 io.katacontainers.config.hypervisor.virtio_extra_arg s 주석이 있는 Pod가 시작되지 않습니다. 이는 OpenShift Container Platform 4.13 및 4.14의 OpenShift 샌드박스 컨테이너 Operator에서 사용하는 virtiofsd 구성 요소의 회귀입니다. OpenShift Container Platform 4.12 및 4.11은 영향을 받지 않습니다. (KATA-2146)
  • 임시 메모리 볼륨의 sizeLimit 옵션은 OpenShift 샌드박스 컨테이너에서 작동하지 않습니다. 임시 볼륨 크기는 기본적으로 샌드박스 컨테이너에 할당된 메모리의 50%입니다. 볼륨을 다시 마운트하여 이 볼륨의 크기를 수동으로 변경할 수 있습니다. 예를 들어 샌드박스 컨테이너에 할당된 메모리가 6GB이고 임시 볼륨이 /var/lib/containers 에 마운트된 경우 다음 명령을 사용하여 VM 메모리의 기본 50% 이상으로 이 볼륨의 크기를 늘릴 수 있습니다.

    $ mount -o remount,size=4G /var/lib/containers

    (KATA-2579)

  • io.katacontainers.config.hypervisor.default_vcpusio.katacontainers.config.hypervisor.default_memory 주석은 QEMU의 의미 체계를 따릅니다. 여기에는 피어 Pod에 대한 다음과 같은 제한 사항이 있습니다.

    • io.katacontainers.config.hypervisor.default_memory 주석의 값을 256 미만으로 설정하면 다음 오류가 발생합니다.

      Failed to create pod sandbox: rpc error: code = Unknown desc = CreateContainer failed: Memory specified in annotation io.katacontainers.config.hypervisor.default_memory is less than minimum required 256, please specify a larger value: unknown
    • io.katacontainers.config.hypervisor.default_memory: 256io.katacontainers.config.hypervisor.default_vcpus: 1 주석을 사용하는 경우 가장 작은 인스턴스가 목록에서 시작됩니다.
    • io.katacontainers.config.hypervisor.default_vcpus: 0 주석을 사용하면 모든 주석이 무시되고 기본 인스턴스가 시작됩니다.

    대신 유연한 Pod VM 크기에 io.katacontainers.config.hypervisor.machine_type: <instance type/instance size > 주석을 사용하는 것이 좋습니다. (KATA-2575, KATA-2577, KATA-2578)

  • OpenShift 샌드박스 컨테이너 Operator 1.4.1에서 버전 1.5로 자동 업그레이드하는 동안 업그레이드가 보류 중 상태로 유지됩니다.

    서브스크립션이 자동 업데이트로 설정된 경우 OpenShift 샌드박스 컨테이너의 업그레이드가 설치됩니다. 그러나 KataConfig CR(사용자 정의 리소스)이 설치된 경우 CSV가 보류 중 상태로 유지됩니다.

    다음 명령을 실행하여 Subscription 오브젝트의 상태를 확인할 수 있습니다.

    $ oc get sub osc-operator -n openshift-osc-operator -o yaml

    다음 오류는 Subscription 오브젝트의 status 섹션과 upgrade InstallPlan 오브젝트의 status 섹션에 표시됩니다.

    message: 'error validating existing CRs against new CRD''s schema for "kataconfigs.kataconfiguration.openshift.io":
          error validating custom resource against new schema for KataConfig /example-kataconfig:
          [].status.runtimeClass: Invalid value: "string": status.runtimeClass in body
          must be of type array: "string"'

    이 오류가 발생하면 OpenShift 샌드박스 컨테이너 Operator를 제거한 다음 다시 설치해야 합니다.

    1. kata 또는 kata-remote 런타임에서 실행되는 모든 워크로드(Pod, 배포, 데몬 세트)를 삭제합니다. 이러한 워크로드를 다시 설치한 후 다시 생성해야 합니다. 워크로드 삭제에 대한 자세한 내용은 CLI를 사용하여 OpenShift 샌드박스 컨테이너 Pod 삭제를 참조하십시오.
    2. KataConfig CR을 삭제합니다. CLI를 사용하여 KataConfig 사용자 지정 리소스 삭제를 참조하십시오.

      중요

      워크로드가 실행 중인 경우 KataConfig CR을 삭제하지 마십시오.

      다음 명령을 사용하여 KataConfig CR의 삭제 상태를 확인할 수 있습니다.

      $ oc get kataconfig -n openshift-osc-operator
    3. Operator를 설치 제거합니다. CLI를 사용하여 OpenShift 샌드박스 컨테이너 Operator 삭제를참조하십시오.
    4. OpenShift 샌드박스 컨테이너 Operator를 다시 설치합니다. CLI를 사용하여 OpenShift 샌드박스 컨테이너 Operator 설치를 참조하십시오.

      OpenShift 샌드박스 컨테이너 Operator를 다시 설치하면 버전 1.5.0이 설치됩니다.

    5. KataConfig CR을 생성합니다. CLI를 사용하여 KataConfig 사용자 지정 리소스 생성을 참조하십시오.
    6. 워크로드를 다시 생성합니다. CLI를 사용하여 샌드박스 컨테이너에 워크로드 배포를 참조하십시오.
    참고

    수동 업데이트로 서브스크립션을 설정하는 경우 OpenShift 샌드박스 컨테이너 Operator 1.5.1을 사용할 수 있을 때까지 업그레이드를 승인하지 마십시오.

    (KATA-2593)

2.5. 비동기 에라타 업데이트

OpenShift 샌드박스 컨테이너 4.15의 보안, 버그 수정 및 개선 사항 업데이트는 Red Hat Network를 통해 비동기 에라타로 릴리스됩니다. 모든 OpenShift Container Platform 4.15 에라타는 Red Hat Customer Portal을 통해 제공됩니다. 비동기 에라타에 대한 자세한 내용은 OpenShift Container Platform 라이프 사이클에서 참조하십시오.

Red Hat Customer Portal 사용자는 Red Hat 서브스크립션 관리(RHSM) 계정 설정에서 에라타 통지를 활성화할 수 있습니다. 에라타 통지가 활성화되면 사용자는 등록된 시스템과 관련된 새 에라타가 릴리스될 때마다 이메일을 통해 통지를 받습니다.

참고

Red Hat Customer Portal 사용자 계정에는 OpenShift Container Platform에서 에라타 통지 이메일을 생성하기 위해 OpenShift Container Platform을 사용할 수 있는 등록된 시스템 및 권한이 필요합니다.

이 섹션은 향후 OpenShift 샌드박스 컨테이너 1.5의 비동기 에라타 릴리스의 개선 사항 및 버그 수정에 대한 정보 제공을 위해 지속적으로 업데이트됩니다.

2.5.1. RHEA-2023:7493 - OpenShift 샌드박스 컨테이너 1.5.0 이미지 릴리스, 버그 수정 및 개선 권고

출시 날짜: 2023-11-27

OpenShift 샌드박스 컨테이너 릴리스 1.5.0이 공개되었습니다. 이 권고에는 개선 사항 및 버그 수정이 포함된 OpenShift 샌드박스 컨테이너 업데이트를 포함합니다.

업데이트에 포함된 버그 수정 목록은 RHEA-2023:7493 권고에 설명되어 있습니다.

2.5.2. RHBA-2024:0147 - OpenShift 샌드박스 컨테이너 1.5.1 이미지 릴리스 및 버그 수정 권고

출시 날짜: 2024-01-11

OpenShift 샌드박스 컨테이너 릴리스 1.5.1이 공개되었습니다. 이 권고에는 버그 수정이 포함된 OpenShift 샌드박스 컨테이너 업데이트가 포함되어 있습니다.

업데이트에 포함된 버그 수정 목록은 RHBA-2024:0147 권고에 설명되어 있습니다.

2.5.3. RHBA-2024:0815 - OpenShift 샌드박스 컨테이너 1.5.2 이미지 릴리스 및 버그 수정 권고

출시 날짜: 2024-02-15

OpenShift 샌드박스 컨테이너 릴리스 1.5.2가 공개되었습니다. 이 권고에는 버그 수정이 포함된 OpenShift 샌드박스 컨테이너 업데이트가 포함되어 있습니다.

업데이트에 포함된 버그 수정 목록은 RHBA-2024:0815 권고에 설명되어 있습니다.

2.5.4. RHBA-2024:2035 - OpenShift 샌드박스 컨테이너 1.5.3 이미지 릴리스 및 버그 수정 권고

출시 날짜: 2024-04-24

OpenShift 샌드박스 컨테이너 릴리스 1.5.3이 공개되었습니다. 이 권고에는 버그 수정이 포함된 OpenShift 샌드박스 컨테이너 업데이트가 포함되어 있습니다.

업데이트에 포함된 버그 수정 목록은 RHBA-2024:2035 권고에 설명되어 있습니다.

법적 공지

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.