kubernetes 네임스페이스를 노드에 연결하는 중

개발, QA 및 프로덕션과 같은 환경을 쿠버네티스 네임스페이스에 매핑하는 것이 좋은 관행인 것 같습니다. "진정한" 분리를 달성하려면 이러한 네임스페이스 중 하나에만 전용 노드에 레이블을 지정하고 해당 환경의 리소스가 해당 노드에서만 예약되도록 하는 것이 좋습니다. 그것은 적어도 우리의 현재 생각이다. 이러한 네임스페이스에 사용하고자 하는 매니페스트가 있을 수 있습니다. 이러한 네임스페이스는 조작해서는 안 됩니다. Kubernetes는 네임스페이스를 기본 노드와 연결하는 것을 지원하지 않는 것 같습니다. 승인 컨트롤러는 가까운 것처럼 보이지만 우리가 원하는 것은 아닙니다. 우리가 원하는 것을 달성할 수 있는 유일한 옵션은 문서화된 대로 사용자 정의 변형 승인 웹 후크인 것 같습니다.

다른 사람들이 이전에 여기에 와 본 적이 있을 것이며, 개발 환경에 로드가 프로덕션 성능에 영향을 미치지 않도록 하는 것이 우리의 주요 문제를 해결할 수 있는 솔루션이 있을 것입니다.

네임스페이스와 노드를 연결하는 기성 솔루션이 있습니까?

그렇지 않은 경우, 환경이 부하/성능 측면에서 간섭하지 않도록 보장하는 대안적인 접근법이 있습니까?

여러 가지 이유로 한 클러스터에 여러 환경을 포함하는 것은 좋지 않은 생각입니다.

프로덕션 포드의 성능을 떨어뜨리고 싶지 않다면 배포/팟에 쉽게 연결할 수 있습니다.

또 다른 접근 방식은 노드에 레이블을 부착하고 PodNode Selector를 사용하여 특정 포드를 노드에 배포하는 것입니다.

다른 사람들이 이전에 여기에 와 본 적이 있을 것이며, 개발 환경에 로드가 프로덕션 성능에 영향을 미치지 않도록 하는 것이 우리의 주요 문제를 해결할 수 있는 솔루션이 있을 것입니다.

거기 갔다가 화상을 입었어요

특정 상황에서는 클러스터 하나에 여러 환경을 포함하는 것이 바람직할 수 있지만 단일 클러스터에서 dev/qa/stage를 운영 환경과 혼합하면 문제가 발생합니다. 특히 적절한 리소스 할당으로 영향을 완화하는 경우 로드 자체는 주요 문제가 아닐 수 있지만, kube-system 포드에 대한 조정, 수정 및 개발 프로세스로 인한 중단은 생산에 직접적인 영향을 미칩니다. 사전에 Kubernetes 시스템 구성 요소에 대한 업데이트를 테스트할 수 없으며, 개발 시 발생하는 모든 cni 문제로 인해 속도가 느려지거나 운영이 불가능해질 수 있습니다. 우리는 그 길을 따라 갔고 그것을 추천하지 않는다.

그런 말이 나왔으니, 그렇게 분리하는 것은 꽤 쉽다. 클러스터 중 하나에서는 일부 프로젝트의 개발/qa/stage 환경을 단일 클러스터에 유지하고 일부 리소스를 레이블로 분리합니다. 엄밀히 말하면 실제로 env로 분리된 것은 아니지만 세 가지 환경, 별도의 gitlab 러너 노드, 데이터베이스 노드 등을 모두 포함하는 엘크 전용 노드가 있지만 원칙은 동일합니다. 특정 작업/서비스(또는 환경) 분리를 위해 동일한 레이블을 사용하여 노드 그룹에 레이블을 지정하고 와 함께 사용합니다. 에 따라 부차적인 주석이 격하됩니다.

일반적으로 네임스페이스를 사용하여 소프트웨어 환경(개발, 테스트, 스테이징, prod 등)을 분리하지 않는 것이 좋습니다.

가장 좋은 방법은 사용하는 것입니다.

비용을 절약하기 위해 다음과 같은 구성 요소를 사용할 수 있습니다.

클러스터 1개: 개발, 테스트, 스테이징
클러스터 1개: prod

이 설정을 사용하면 개발, 테스트 및 스테이징을 위해 공유되는 클러스터의 리소스 네임스페이스를 생성하는 작업이 조금 더 번거로워집니다.

병원에서 찾았어요

노드 집합이 네임스페이스의 리소스에 있는지 확인해야 하는 경우 다음을 함께 사용해야 합니다.

podSelector 세트의 노드에서만 리소스 예약을 강제로 적용하다
그리고 a

노드 집합만 사용하는 전용 네임스페이스를 만드는 방법: