2.5. 버그 수정
이번 릴리스에서는 다음 구성 요소에 대한 버그가 수정되었습니다.
빌드
- ConfigMap 빌드 소스를 사용하면 ConfigMap을 빌드 소스로 사용할 수 있으며 이는 보안보다 투명하고 유지 관리가 쉽습니다. ConfigMap은 모든 OpenShift 빌드에 삽입할 수 있습니다. (BZ#1540978)
- OOM(메모리 부족) 종료된 빌드 Pod에 대한 정보는 빌드 오브젝트로 전파됩니다. 이 정보는 디버깅을 단순화하고 적절한 실패 이유를 사용자에게 설명하는 경우 잘못된 항목을 검색하는 데 도움이 됩니다. 빌드 컨트롤러는 빌드 Pod가 OOM 종료된 경우 상태 이유 및 메시지를 올바르게 채웁니다. (BZ#1596440)
- 빌드 상태를 업데이트하기 위한 논리는 빌드 상태가 failed 상태로 변경된 후에만 빌드 로그의 tail이 포함된 로그 코드 조각을 업데이트하도록 대기했습니다. 빌드는 먼저 실패 상태로 전환된 다음 로그 코드 조각을 사용하여 다시 업데이트합니다. 즉, 빌드가 실패 상태가 될 수 있는 코드 감시에 처음에는 로그 스니펫 값이 표시되지 않습니다. 빌드가 실패 상태로 전환되면 로그 코드 조각 필드를 채우도록 코드가 변경되어 빌드 업데이트에 실패한 상태와 로그 스니펫이 모두 포함됩니다. 실패 상태로 전환하는 빌드를 감시하는 코드는 나중에 후속 업데이트가 표시되지 않고 빌드를 실패로 전환한 업데이트의 일부로 로그 스니펫이 표시됩니다. (BZ#1596449)
-
JenkinsPipelineStrategy빌드 전략을 사용한 작업이 있으면 정리 설정이 무시되었습니다. 결과적으로successfulBuildsHistoryLimit 및을 설정하면 이전 작업을 올바르게 정리하지 않았습니다. 작업을 올바르게 정리하도록 코드가 변경되었습니다. (BZ#1543916)failedBuildsHistoryLimit
클라우드 컴퓨팅
-
이제 설치 중에
dns=none에 맞게 NetworkManager를 구성할 수 있습니다. 이 구성은 일반적으로 Microsoft Azure에 OpenShift Container Platform을 배포할 때 사용되지만 다른 시나리오에서도 유용할 수 있습니다. 이를 구성하려면openshift_node_dnsmasq_disable_network_manager_dns=true를 설정합니다. (BZ#1535340)
Image
- 이전 버전에서는 빈 이미지 스트림 업데이트를 잘못 처리하기 때문에 태그를 변경하지 않은 이미지 스트림을 업데이트하면 이미지 가져오기 API에 대한 요청이 생성되어 가져올 콘텐츠가 포함되지 않았습니다. 이로 인해 컨트롤러에서 오류가 발생했습니다. 이제 가져와야 하는 새 태그 또는 업데이트된 태그가 없는 이미지 스트림을 업데이트해도 API 가져오기가 발생하지 않습니다. 이번 수정으로 잘못된 요청은 가져오기 API로 이동하지 않으며 컨트롤러에서 오류가 발생하지 않습니다. (BZ#1613979)
- Blob을 삭제하는 동안 예기치 않은 오류가 발생하는 경우 이미지 정리가 중지되었습니다. 이미지 삭제 오류의 경우 이미지 정리가 etcd에서 이미지 오브젝트를 제거하지 못했습니다. 이제 이미지가 분리된 작업에서 동시에 정리됩니다. 결과적으로 예기치 않은 단일 Blob 삭제 실패 시 이미지 정리가 중지되지 않습니다. (BZ#1567657)
설치 프로그램
-
AWS에 배포할 때
build_ami플레이가 /var/lib/cloud 를 정리하지 못했습니다. 불명확한 /var/lib/cloud 디렉토리로 인해 cloud-init가 실행을 건너뜁니다. 실행을 건너뛰면 새로 배포된 노드가 부트스트랩에 실패하고 OpenShift Container Platform에 자동 등록되지 않습니다. 이 버그 수정을 통해seal_ami플레이 중에 /var/lib/cloud 디렉터리가 정리됩니다. (BZ#1599354) -
설치 프로그램에서 기본적으로 라우터의 확장 경로 검증을 활성화합니다. 이 검증은 경로의 TLS 구성 및 인증서의 추가 검증 및 삭제를 수행합니다. 확장 경로 검증이 OpenShift Container Platform 3.3의 라우터에 추가되었으며 OpenShift Container Platform 3.6의 인증서 삭제로 개선되었습니다. 그러나 이전에는 설치 프로그램에서 확장 경로 검증을 활성화하지 않았습니다. 유효성 검사가 너무 엄격하고 유효한 경로 및 인증서를 거부할 수 있으므로 기본적으로 비활성화될 수 있습니다. 그러나 새 설치에서 기본적으로 사용하도록 설정하는 것이 안전하다고 판단되었습니다. 결과적으로 새 클러스터에서 확장 경로 검증이 기본적으로 활성화됩니다. Ansible 인벤토리에서
openshift_hosted_router_extended_validation=False를 설정하여 를 사용하여 비활성화할 수 있습니다. 기존 클러스터를 업그레이드해도 확장 경로 검증이 활성화되지 않습니다. (BZ#1542711) - OpenShift Container Platform을 통해 로드 밸런서 서비스를 요청하면 완전히 정의된 azure.conf 파일이 없으면 로드 밸런서에서 외부 IP 주소를 완전히 등록하고 제공하지 않습니다. 이제 필요한 모든 변수가 있는 azure.conf 를 사용하면 로드 밸런서를 배포하고 외부 IP 주소를 제공할 수 있습니다. (BZ#1613546)
CRI-O를 OpenShift Container Platform의 container-runtime으로 쉽게 사용하려면 node-config.yaml 파일을 올바른 끝점 설정으로 업데이트합니다.
openshift_node_groups기본값이 각 기본 노드 그룹에 대해 CRI-O 변형을 포함하도록 확장되었습니다. 컴퓨팅 노드 그룹에 CRI-O 런타임을 사용하려면 다음 인벤토리 변수를 사용합니다.-
openshift_use_crio=True openshift_node_group_name="node-config-compute-crio"또한 Docker 가비지 컬렉터인
docker gc를 배포하려면 다음 변수를True로 설정해야 합니다. 이 버그 수정을 통해 이전 변수 기본값을True에서False로변경합니다.-
openshift_crio_enable_docker_gc=True(BZ#1615884)
-
-
openshift-ansible과 함께 배포된 ansible.cfg 파일은 이제 ~/openshift-ansible.log 의 기본 로그 경로를 설정합니다. 이렇게 하면 기본적으로 로그가 예측 가능한 위치에 기록됩니다. 배포된 ansible.cfg 파일을 사용하려면 먼저 Ansible 플레이북을 실행하기 전에 디렉터리를 /usr/share/ansible/openshift-ansible 으로 변경해야 합니다. 이 ansible.cfg 파일은openshift-ansible의 성능 및 안정성을 향상시키는 다른 옵션도 설정합니다. (BZ#1458018) -
동적 스토리지 프로비저닝을 사용하여 다중 영역 또는 리전 클러스터에 Prometheus를 설치하면 경우에 따라 Prometheus Pod를 예약할 수 없습니다. Prometheus 포드에는 세 개의 물리 볼륨(Prometheus 서버용 1개, Alertmanager용) 및 alert-buffer용 볼륨이 필요합니다. 동적 스토리지가 있는 다중 영역 클러스터에서 이러한 볼륨 중 하나 이상이 다른 영역에 할당될 수 있습니다. 이로 인해 클러스터의 각 노드로 인해 자체 영역의 물리 볼륨에만 액세스할 수 있으므로 Prometheus Pod를 예약할 수 없습니다. 따라서 노드는 Prometheus Pod를 실행하고 세 개의 물리 볼륨에 모두 액세스할 수 없습니다. 권장되는 솔루션은
zone:매개 변수를 사용하여 볼륨을 단일 영역으로 제한하고 Ansible 설치 프로그램 인벤토리 변수인openshift_prometheus_<COMPONENT>_storage_class=<zone_restricted_storage_class>를 사용하여 이 스토리지 클래스를 Prometheus 볼륨에 할당하는 스토리지 클래스를 생성하는 것입니다.이 문제를 해결하면 동일한 영역 또는 지역에서 세 개의 볼륨이 모두 생성되고 Prometheus Pod는 동일한 영역의 노드에 자동으로 예약됩니다. (BZ#1554921)
로깅
-
이전 버전에서는
openshift-ansible 설치 프로그램에서는shared_ops만 지원했으며 Kibana 인덱스 방법으로고유했습니다. 이 버그 수정을 통해 EFK 클러스터 이외의 사용자는 Kibana에서 기본 인덱스를 공유하고 쿼리, 대시보드 등을 공유할 수 있습니다. (BZ#1608984) - ES5 스택을 설치하는 과정에서 사용자는 ES가 실행되는 노드의 sysctl 파일을 생성해야 합니다. 이 버그 수정에서는 작업을 실행할 노드/Ansible 호스트를 평가합니다. (BZ#1609138)
- 기본 제공 메모리에서 주기적으로 다시 시작되지 않도록 Prometheus 지표를 지원하고 대기열을 재시도하려면 추가 메모리가 필요합니다. 이 버그 수정을 통해 Fluentd에 대한 out-of-the-box 메모리가 증가합니다. 결과적으로 Fluentd Pod는 즉시 사용 가능한 메모리 재시작을 방지합니다. (BZ#1590920)
- 이제 Fluentd는 기본적으로 100개의 작업마다 Elasticsearch에 다시 연결됩니다. 클러스터의 다른 Elasticsearch보다 먼저 하나의 Elasticsearch가 시작되면 Elasticsearch 서비스의 로드 밸런서가 해당 하나와 그에만 연결되므로 Fluentd가 모두 Elasticsearch에 연결됩니다. 이번 개선된 기능을 통해 Fluentd를 정기적으로 다시 연결하면 로드 밸런서가 클러스터의 모든 Elasticsearch에 부하를 균등하게 분산할 수 있습니다. (BZ#1489533)
-
rubygem ffi 1.9.25는 패치를 되돌려서 SELinux
deny_execmem=1인 시스템에서 작동할 수 있었습니다. 이 경우 Fluentd가 충돌합니다. 이번 버그 수정에서는 패치 리버전을 되돌리고 결과적으로 SELinuxdeny_execmem=1을 사용할 때 Fluentd가 충돌하지 않습니다. (BZ#1628407)
관리 콘솔
- 로그 뷰어가 여러 줄 또는 부분 행 응답을 고려하지 않았습니다. 응답에 여러 줄 메시지가 포함된 경우 한 줄로 추가되고 처리되어 행 번호가 올바르지 않습니다. 이와 유사하게 부분 줄이 수신되면 전체 행으로 처리되고 긴 로그 행이 여러 행으로 분할되어 행 수가 다시 올바르지 않게 됩니다. 이 버그 수정을 통해 로그 뷰어에 논리가 추가되어 여러 줄 및 부분 행 응답을 고려합니다. 결과적으로 행 번호가 정확합니다. (BZ#1607305)
모니터링
-
9100포트는 기본적으로 모든 노드에서 차단되었습니다. Prometheus는9100포트에서 수신 대기하는 다른 노드에서 실행 중인node_exporter서비스를 스크랩할 수 없습니다. 이번 버그 수정을 통해9000~1000포트 범위에 대해 들어오는 TCP 트래픽을 허용하도록 방화벽 구성을 수정합니다. 결과적으로 Prometheus에서node_exporter서비스를 스크랩할 수 있습니다. (BZ#1563888) -
node_exporter는 기본적으로 활성화되어있는PROJECT 컬렉터로 시작합니다. ❏수집기는 활성화되지 않은 SELinux 권한이 필요하며, 이로 인해node_exporter를 중지하지 않지만 AVC가 거부됩니다. 이 버그 수정을 통해node_exporter가 프리뷰 컬렉터를명시적으로 비활성화하여 시작됩니다. 결과적으로 SELinux는 더 이상 AVC 거부를 보고하지 않습니다. (BZ#1593211) -
Prometheus를 설치 제거하면 현재 전체
openshift-metrics네임스페이스가 삭제됩니다. 이는 동일한 네임스페이스에서 생성되었지만 Prometheus 설치의 일부가 아닌 오브젝트를 삭제할 수 있습니다. 이번 버그 수정을 통해 Prometheus 설치에서 생성된 특정 오브젝트만 삭제하고 나머지 오브젝트가 없는 경우 네임스페이스를 삭제하도록 설치 제거 프로세스를 변경하여 다른 오브젝트와 네임스페이스를 공유하는 동안 Prometheus를 설치하고 제거할 수 있습니다. (BZ#1569400)
Pod
-
이전에는 Pod에서 오류가 반환될 때 Kubernetes 버그로 인해
kubectl drain이 중지되었습니다. Kubernetes 수정을 통해 포드에서 오류를 반환하면 명령이 더 이상 중단되지 않습니다. (BZ#1586120)
라우팅
- OpenShift Extended Comformance Tests 및 Node Vertical Test 이후에 dnsmasq가 중단되고 새 포드가 생성되지 않았습니다. 코드를 변경하면 노드가 테스트를 통과할 수 있도록 열린 파일 설명자의 최대 수가 증가합니다. (BZ#1608571)
-
경로에서
haproxy.router.openshift.io/ip_whitelist주석을 사용하여 62개 이상의 IP 주소를 지정하면 명령에서 최대 매개 변수를 초과하여 라우터가 오류가 발생합니다(63). 라우터가 다시 로드되지 않습니다. whitelist 주석에 IP가 너무 많으면 오버플로 맵을 사용하도록 코드가 변경되어 맵을 HA-proxy ACL에 전달합니다. (BZ#1598738) -
설계에 따라 여러 서비스가 포함된 경로를 사용하여
route-backend를서비스를 구성할 때 weight는 기존의 모든 연결 및 관련 최종 사용자 연결을 삭제합니다. 이 버그 수정을 통해 값이0으로 설정하여0이면 서버가 부하 분산에 참여하지 않지만 지속적인 연결을 계속 허용합니다. (BZ#1584701) -
활성 상태 및 준비 상태 프로브가 활성 상태인 Pod와 준비된 Pod를 구분할 수 없기 때문에
ROUTER_BIND_PORTS_AFTER_SYNC=true가 있는 라우터가 실패로 보고되었습니다. 이 버그 수정을 통해 활성 및 준비 프로브를 별도의 프로브(준비 상태 및 활성 상태)로 분할합니다. 결과적으로 라우터 포드가 활성 상태일 수 있지만 아직 준비되지 않았습니다. (BZ#1550007) - HAproxy 라우터에 많은 수의 경로( 10,000개 이상)가 포함된 경우 라우터는 낮은 성능으로 인해 활성 및 준비 상태를 전달하지 않으므로 라우터가 반복적으로 종료됩니다. 이 문제의 근본 원인은 기본 준비 및 활성 감지 주기 내에서 상태 점검을 완료할 수 없기 때문입니다. 이 문제를 방지하려면 프로브 간격을 늘립니다. (BZ#1595513)
서비스 브로커
- Ansible 서비스 브로커의 프로비저닝 해제 프로세스에서 openshift-ansible-service-broker 프로젝트에서 시크릿을 삭제하지 않았습니다. 이 버그 수정으로 Ansible Service Broker 제거 시 연결된 모든 시크릿을 삭제하도록 코드가 변경되었습니다. (BZ#1585951)
- 이전에는 브로커의 조정 기능이 레지스트리에서 업데이트된 정보를 얻기 전에 이미지 참조를 삭제했으며, 다른 작업이 실행 중인 동안 브로커의 데이터 저장소에 레코드가 표시되기 전까지는 기간이 있었습니다. 변경된 항목에 대한 즉각적 업데이트를 수행하도록 조정 기능이 다시 설계되었습니다. 레지스트리에서 제거된 항목의 경우 브로커는 아직 프로비저닝되지 않은 항목만 삭제합니다. 또한 해당 항목을 UI에서 필터링하여 해당 항목의 향후 프로비저닝을 방지하는 삭제 항목을 표시합니다. 결과적으로 브로커의 조정 기능을 사용하면 프로비저닝 및 레지스트리 변경에 대한 복원력이 향상됩니다. (BZ#1577810)
-
이전에는 항목을 찾을 수 없는 경우 정상적으로 찾을 수 없는 경우에도 오류 메시지가 표시되었습니다. 결과적으로 성공한 작업에 오류 메시지가 기록되어 사용자가 없을 때 문제가 발생할 수 있습니다. 메시지의 로깅 수준은 여전히 디버깅 목적에 유용하지만 수준이
info이상으로 설정된 프로덕션 설치에는 유용하지 않으므로 이제error에서debug로 변경되었습니다. 따라서 실제 문제가 없으면 사용자는 인스턴스를 찾을 수 없는 경우 오류 메시지가 표시되지 않습니다. (BZ#1583587) -
클러스터가 실행 중이 아니거나 연결할 수 없는 경우
svcat version명령에서 오류가 발생합니다. 항상 클라이언트 버전을 보고하도록 코드가 변경되었으며 서버에 연결할 수 있는 경우 서버 버전을 보고합니다. (BZ#1585127) -
일부 시나리오에서는
svcat deprovision <service-instance-name> --wait명령을 사용하면 패닉 오류가 발생하여svcat명령이 종료되는 경우가 있었습니다. 이 문제가 발생하면프로비저닝 해제명령이 실행된 후 프로그램이 인스턴스가 완전히 프로비저닝 해제될 때까지 기다리려고 할 때 코드 버그가 발생했습니다. 이 문제는 이제 해결되었습니다. (BZ#1595065)
스토리지
- 이전 버전에서는 kubelet 시스템 컨테이너가 /var/lib/iscsi 디렉터리에 쓸 수 없기 때문에 iSCSI 볼륨을 연결할 수 없었습니다. 이제 iSCSI 볼륨을 연결할 수 있도록 /var/lib/iscsi 호스트를 kubelet 시스템 컨테이너에 마운트할 수 있습니다. (BZ#1598271)
