검색

1.13.2. 확인된 문제

download PDF
  • OpenShift Serverless 1.16.0으로 업그레이드하기 전에 OpenShift Container Platform을 버전 4.6.30, 4.7.11 이상으로 업그레이드해야 합니다.
  • AMQ Streams Operator는 OpenShift Serverless Operator를 설치하거나 업그레이드하지 못할 수 있습니다. 이 경우 OLM(Operator Lifecycle Manager)에 의해 다음 오류가 발생합니다.

    WARNING: found multiple channel heads: [amqstreams.v1.7.2 amqstreams.v1.6.2], please check the `replaces`/`skipRange` fields of the operator bundles.

    OpenShift Serverless Operator를 설치하거나 업그레이드하기 전에 AMQ Streams Operator를 설치 제거하여 이 문제를 해결할 수 있습니다. 그런 다음 AMQ Streams Operator를 다시 설치할 수 있습니다.

  • Service Mesh가 mTLS를 사용하여 사용하도록 설정된 경우 Service Mesh가 Prometheus의 메트릭 스크랩을 허용하지 않기 때문에 기본적으로 Knative Serviceing에 대한 메트릭이 사용되지 않도록 설정됩니다. Service Mesh 및 mTLS에서 사용할 Knative Serving 메트릭 활성화에 대한 자세한 내용은 Serverless 문서의 "OpenShift Serverless와 Service Mesh 통합" 섹션을 참조하십시오.
  • Istio 수신이 활성화된 Service Mesh CR을 배포하는 경우 istio-ingressgateway Pod에 다음 경고가 표시될 수 있습니다.

    2021-05-02T12:56:17.700398Z warning envoy config [external/envoy/source/common/config/grpc_subscription_impl.cc:101] gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) 0.0.0.0_8081: duplicate listener 0.0.0.0_8081 found

    Knative 서비스에 액세스할 수도 없습니다.

    다음 해결 방법을 사용하여 knative-local-gateway 서비스를 다시 생성하여 이 문제를 해결할 수 있습니다.

    1. istio-system 네임스페이스에서 기존 knative-local-gateway 서비스를 삭제합니다.

      $ oc delete services -n istio-system knative-local-gateway
    2. 다음 YAML이 포함된 knative-local-gateway 서비스를 생성하고 적용합니다.

      apiVersion: v1
      kind: Service
      metadata:
       name: knative-local-gateway
       namespace: istio-system
       labels:
         experimental.istio.io/disable-gateway-port-translation: "true"
      spec:
       type: ClusterIP
       selector:
         istio: ingressgateway
       ports:
         - name: http2
           port: 80
           targetPort: 8081
  • 클러스터에 1000개의 Knative 서비스가 있는 경우 Knative Serving 의 재설치 또는 업그레이드를 수행하면 KnativeServing CR(사용자 정의 리소스)이 Ready 된 후 첫 번째 새 서비스를 생성할 때 지연이 발생합니다.

    3scale-kourier-control 서비스는 새 서비스를 처리하기 전에 기존의 모든 Knative 서비스를 조정하므로 새 서비스가 상태가 Ready로 업데이트되기 전에 IngressNotConfigured 또는 Unknown 상태에서 약 800초를 사용합니다.

  • Kafka 채널 또는 새 Kafka 소스에 대한 새 서브스크립션을 생성하는 경우 새로 생성된 서브스크립션 또는 싱크에서 준비 상태를 보고한 후 Kafka 데이터 플레인에서 메시지를 디스패치할 준비가 되는데 지연이 있을 수 있습니다.

    결과적으로 데이터 플레인에서 준비 상태를 보고하지 않는 시간 동안 전송되는 메시지는 구독자 또는 싱크로 전달되지 않을 수 있습니다.

    이 문제 및 가능한 해결 방법에 대한 자세한 내용은 기술 문서 #6343981을 참조하십시오.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.