2.8. 비동기 에라타 업데이트
OpenShift Container Platform 3.11의 보안, 버그 수정 및 개선 업데이트는 Red Hat Network를 통해 비동기 에라타로 릴리스됩니다. 모든 OpenShift Container Platform 3.11 에라타는 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 Container Platform 3.11과 관련된 비동기 에라타 릴리스의 개선 사항 및 버그 수정에 대한 정보 제공을 위해 지속적으로 업데이트됩니다. OpenShift Container Platform 3.11.z와 같은 비동기 버전 릴리스 정보는 하위 섹션에 자세히 설명되어 있습니다. 또한 공간 제한으로 인해 릴리스 정보에 포함되지 않은 에라타 컨텐츠도 다음 하위 섹션에 자세히 설명되어 있습니다.
OpenShift Container Platform 릴리스의 경우 항상 클러스터 업그레이드 지침을 확인하십시오.
2.8.1. RHBA-2018:3537 - OpenShift Container Platform 3.11.43 버그 수정 및 개선 사항 업데이트
출시 날짜: 2018-11-19
OpenShift Container Platform 릴리스 3.11.43이 공개되었습니다. 업데이트에 포함된 패키지 및 버그 수정 목록은 RHBA-2018:3537 권고에 설명되어 있습니다. 업데이트에 포함된 컨테이너 이미지는 RHBA-2018:3536 권고를 통해 제공됩니다.
권고에서 이 릴리스의 모든 버그 수정 및 개선 사항을 문서화하는 것은 제외되었습니다. 이 릴리스에 포함된 버그 수정 및 개선 사항에 대한 자세한 내용은 다음 섹션을 참조하십시오.
2.8.1.1. 버그 수정
- CRI-O Pod의 로그 메시지를 기본적으로 중간으로 분할할 수 있습니다. 결과적으로 부분 로그 메시지가 Elasticsearch에 인덱싱되었습니다. 최신 fluent-plugin-concat은 CRI-O 스타일 분할 메시지를 하나로 병합할 수 있으며 OpenShift Container Platform 로깅 v3.11에서 사용하는 현재 fluentd(v0.12)에서는 사용할 수 없습니다. 이 기능은 fluentd v0.12로 백포트되었습니다. 이 버그 수정을 통해 CRI-O 스타일 분할 로그 메시지가 원래 전체 메시지로 다시 병합됩니다. (BZ#1552304)
이벤트 라우터에서 중복 이벤트 로그를 의도적으로 생성하여 손실되지 않도록 합니다.
elasticsearch_genid
플러그인은 이제elasticsearch_genid_ext
로 확장되어alt_key 및
를 사용합니다. 로그 메시지에alt_
tagalt_tag
값과 일치하는 태그가 있는 경우alt_key
값을 Elasticsearch 기본 키로 사용합니다. 중복 이벤트에서alt_key
에 공유하는 필드를 지정할 수 있으므로 Elasticsearch에서 중복 이벤트를 제거할 수 있습니다.elasticsearch_genid_ext
를 사용한 샘플 필터 :@type elasticsearch_genid_ext hash_id_key viaq_msg_id alt_key kubernetes.event.metadata.uid alt_tags "#{ENV['GENID_ALT_TAG'] || 'kubernetes.var.log.containers.kube-eventrouter-*.** kubernetes.journal.container._default_.kubernetes.event'}" </filter>
이번 버그 수정으로 Elasticsearch에서 중복 이벤트 로그가 인덱싱되지 않습니다. (BZ#1613722)
- Netty 종속성은 힙을 효율적으로 사용하지 않습니다. 따라서 Elasticsearch는 높은 로깅 볼륨의 네트워크 계층에서 실패하기 시작합니다. 이 버그 수정을 통해 Netty recycler가 비활성화되어 Elasticsearch가 연결을 처리하는 데 더 효율적입니다. (BZ#1627086)
-
설치 프로그램에서 Elasticsearch Pod에서 사용하는 configmap을 매개 변수화하지 않았습니다. 작업 Elasticsearch Pod에서 작동하지 않는 Elasticsearch Pod의 configmap을 사용했습니다. Pod에서
logging-es-ops
configmap을 사용하도록 설치 프로그램에서 사용하는 템플릿을 매개 변수화합니다. (BZ#1627689) - journald 로그 드라이버와 함께 docker를 사용하면 시스템 및 일반 Docker 컨테이너 로그를 포함한 모든 컨테이너 로그가 저널에 기록되며 fluentd에서 읽습니다. 결과적으로 fluentd는 이러한 비Kubernetes 컨테이너 로그를 처리하는 방법을 모르고 예외가 발생합니다. Kubernetes 이외의 컨테이너 로그를 다른 시스템 서비스의 로그로 처리합니다(예: 작업 인덱스로 전송). 이제 Kubernetes 이외의 컨테이너의 로그가 올바르게 인덱싱되어 오류가 발생하지 않습니다. (BZ#1632364)
-
log-driver journald와 함께 docker를 사용하는 경우 /etc/sysconfig/docker 의 설정이
--log-driver
=journald 대신 --log-driver journald
를 사용하도록 변경되었습니다. Fluentd는 journald가 사용되는 것을 감지할 수 없으므로json-file
을 가정하고 journaldCONTAINER_NAME
필드를 찾지 않기 때문에 Kubernetes 메타데이터를 읽을 수 없습니다. 이로 인해 많은 유창한 오류가 발생합니다. Fluentd가 --log-driver=journald 외에
이제 Fluentd가 Docker 로그 드라이버를 감지하고 Kubernetes 컨테이너 로그를 올바르게 처리할 수 있습니다. (BZ#1632648)--log-driver
journald를 찾도록 Docker 로그 드라이버를 감지하는 방법을 변경합니다. fluentd가 컬렉터와 MUX의 조합으로 구성되면 이벤트의 이벤트 로그는 MUX에서 처리해야 했습니다. MUX에서 두 MUX
_CLIENT_MODE 최대값 및 최소값의 수집기가 아니라 MUX
에서 이벤트 로그를 처리해야 했습니다. 이는 이벤트 로그가 수집기에 포맷되고 이벤트 레코드가 Kubernetes 키 아래에 배치되면 로그가 MUX로 전달되고 k8s-meta 플러그인으로 전달되고 기존 Kubernetes 레코드가 덮어쓰기되기 때문입니다. 로그에서 이벤트 정보를 삭제했습니다.수정 1: 교체를 방지하기 위해 로그가 이벤트 라우터에 있는 경우 input-post-forward-mux
.conf의 태그가 ${tag}.
raw 로 다시 작성되어MUX_CLIENT_MODE=minimal 방식으로
로그를 처리합니다.수정 2: Ansible에는 또 다른 버그가 있었습니다. 즉,
openshift_logging_install
가 MUX에서 설정되지 않았습니다._eventrouter가
EVENTStrue
로 설정된 경우에도 환경 변수 TRANSFORM_이 두 가지 버그 수정을 통해 MUX가
MUX_CLIENT_MODE=maximal
및 최소로 구성된 경우 이벤트 로그가 올바르게 기록됩니다. (BZ#1632895)-
OpenShift Container Platform 3.10 이상에서는 API 서버가 정적 포드로 실행되며 해당 pod 내부에 마운트된 /etc/origin/master 및 /var/lib/origin 만 마운트됩니다. 호스트에서 신뢰하는 Cas는 API 서버에서 신뢰하지 않았습니다. API 서버 포드 정의에서 /etc/pki 를 포드에 마운트합니다. API 서버는 설치 프로그램 변수
openshift_additional_ca에서 정의한 인증 기관을 포함하여 호스트에서 신뢰하는 모든 인증 기관을 신뢰합니다
. 개인 CA에서 확인한 레지스트리에서 이미지 스트림을 가져오는 데 사용할 수 있습니다. (BZ#1641657) - Service Catalog 컨트롤러 Pod에서 사용하는 OSB 클라이언트 라이브러리가 종료되지 않았으며 브로커와 통신하는 데 사용되는 TCP 연결이 해제되었습니다. 일정 기간 동안 많은 TCP 연결이 열려 있어 결국 Service Catalog 컨트롤러와 브로커 간의 통신이 실패했습니다. 또한 포드는 응답하지 않습니다. OSB 클라이언트 라이브러리를 사용할 때 TCP 연결을 재사용합니다. (BZ#1641796)
- S2I를 사용하여 증분 빌드를 선택하면 이전 빌드의 아티팩트를 재사용하지 못할 수 있었습니다. 이는 재사용되는 아티팩트의 크기가 특히 크거나 호스트 시스템이 특히 느리게 실행되는 경우에 발생할 수 있습니다. 이후 빌드에서 유효하지 않은 아티팩트를 사용하거나 재사용하지 않고 아티팩트를 다시 생성하면 성능 저하가 발생합니다. 이 버그 수정을 통해 이 문제를 피하기 위해 시간 초과가 충분히 큰 값으로 증가합니다. 아티팩트 재사용은 더 이상 시간 초과되지 않습니다. (BZ#1642350)
- Automation Broker는 항상 대상 네임스페이스에 대한 임시 네임스페이스 액세스를 제공하기 위해 네트워크 정책을 생성했습니다. 다른 네트워크 정책이 없는 네임스페이스에 네트워크 정책을 추가하면 새로 생성된 정책으로 네임스페이스가 잠깁니다. 네트워크 정책 이전에는 모든 것이 열려 있었으며 네임스페이스가 서로 통신할 수 있었습니다. 이제 Automation Broker에서 대상 네임스페이스에 대한 네트워크 정책이 있는지 확인합니다. 없는 경우 브로커는 새 네트워크 정책을 생성하지 않습니다. 브로커는 사용자가 생성한 임시 네임스페이스가 대상 네임스페이스와 통신할 수 있을 만큼 충분히 열려 있다고 가정합니다. 대상 네임스페이스에 대한 다른 네트워크 정책이 있는 경우 브로커는 대상 네임스페이스에 대한 임시 네임스페이스 액세스를 제공하는 네트워크 정책을 생성합니다. 이 버그 수정을 통해 브로커는 대상 네임스페이스에서 실행되는 기존 서비스에 영향을 주지 않고 APB 작업을 수행할 수 있습니다. (BZ#1643301)
-
이전에는 Pod가 크래시 루프 상태에 있는 경우에도 OpenShift Container Platform 3.11의 클러스터 콘솔에 클러스터 상태 페이지의 크래시 루프 상태 페이지의 값
0
이 항상 표시되었습니다. 이제 문제가 해결되어 이제 선택한 프로젝트의 개수가 정확히 반영됩니다. (BZ#1643948)
2.8.1.2. 업그레이드
기존 OpenShift Container Platform 3.10 또는 3.11 클러스터를 최신 릴리스로 업그레이드하려면 업그레이드 방법 및 전략을 참조하십시오.