☰

Docker 스타일 링크와 Pod 환경 변수의 충돌 방지

tag-icon • tag-icon kubernetes environment-variables
Docker 스타일 링크와 Pod 환경 변수의 충돌 방지

Docker를 컨테이너 런타임으로 사용하여 Kubernetes에서 구성 요소를 실행합니다. 문제는 Pod 환경이 다음과 같은 Docker 스타일 링크 변수로 오염된다는 것입니다.

  • SERVICENAME_PORT_8181_TCP
  • SERVICENAME_PORT_HTTP
  • .....
  • SERVICENAME_PORT

표시되는 각 서비스(동일한 네임스페이스에 있는 서비스)에 대해. 이 상황에서는 자동으로 생성된 변수가 명시적으로 선언된 환경과 충돌하기가 쉽습니다. 이로 인해 때로는 진단하기 어려운 문제가 발생합니다. 또한 컨테이너가 Kubernetes 서비스 구성의 세부 사항에 의존하지 않는 것을 선호하므로 이러한 자동 변수에 의존하고 싶지 않습니다. 현재 이러한 충돌을 피하기 위해 명시적 변수에 고유한 이름 접두사를 추가하고 있습니다.

표시되는 각 서비스에 대해 자동 변수를 추가하지 않도록 클러스터를 구성하는 방법이 있습니까? 또는 containerd이 문제를 해결하는 것과 같은 다른 런타임을 사용하시겠습니까? 환경 변수를 통한 구성이 좋은 방법으로 간주되기 때문에 쉽게 검색할 수 있는 솔루션이 없다는 사실에 놀랐습니다. 일반적으로 이러한 이름 충돌이 발생하지 않고 환경을 사용하려면 어떻게 해야 합니까? 아니면 서비스 이름은 컨테이너와의 계약의 일부로 간주되므로 임의로 변경하면 안 되나요?

답변1

표시되는 각 서비스에 대해 자동 변수를 추가하지 않도록 클러스터를 구성하는 방법이 있습니까?

예 및 아니요: 클러스터 전체, AFAIK는 아니지만enableServiceLinks: false필드spec:스위치를 끌 수 있도록 설계되었습니다.

아니면 Containerd와 같은 다른 런타임을 사용하면 이 문제가 해결됩니까?

아니요, 해당 이름은 docker와의 호환성을 위해 추가되었지만 docker와 전혀 관련이 없습니다.kubelet에 의해 주입됨

일반적으로 이러한 이름 충돌이 발생하지 않고 환경을 사용하려면 어떻게 해야 합니까? 아니면 서비스 이름은 컨테이너와의 계약의 일부로 간주되므로 임의로 변경하면 안 되나요?

또 다른 옵션은 이를 전면적으로 금지하는 것보다는 그냥 마스킹하는 것입니다.특정한앱을 방해하는 것; 끝나는 것들은 _HTTPSpring Boot에서 특히 문제가 됩니다. 여기에는 Service또는 같은 metadata: { name:매우 일반적인 이름이 있습니다.serviceserver

배포별로 이를 수행할 수 있습니다.

env:
- name: SERVICENAME_PORT_HTTP
  # omitting the value: just sets it to the empty string in the container
# and the rest

또는 공격적인 항목이 포함된 ConfigMap을 선언하고 전체적으로 덮어쓸 수 있습니다 envFrom:(영향을 받는 각 배포를 패치할 필요가 없도록 하기 위해).

관련 정보