Kubernetes 모범 사례. 네임스페이스가 있는 Kubernetes의 구성

Kubernetes 모범 사례. 작은 컨테이너 만들기

점점 더 많은 Kubernetes 서비스를 생성하기 시작하면 처음에는 단순했던 작업이 더욱 복잡해지기 시작합니다. 예를 들어 개발팀은 동일한 이름으로 서비스나 배포를 생성할 수 없습니다. 수천 개의 포드가 있는 경우 적절하게 관리하는 것은 물론이고 단순히 나열하는 데도 많은 시간이 걸립니다. 그리고 이것은 빙산의 일각에 불과합니다.

네임스페이스를 사용하여 Kubernetes 리소스를 더 쉽게 관리하는 방법을 살펴보겠습니다. 그렇다면 네임스페이스란 무엇일까요? 네임스페이스는 Kubernetes 클러스터 내의 가상 클러스터로 생각할 수 있습니다. 단일 Kubernetes 클러스터 내에서 여러 네임스페이스를 서로 격리할 수 있습니다. 이는 조직, 보안, 심지어 시스템 성능까지 귀하와 귀하의 팀에 실제로 도움이 될 수 있습니다.

대부분의 Kubernetes 배포판에서 클러스터는 "default"라는 네임스페이스와 함께 기본적으로 제공됩니다. 실제로 Kubernetes가 다루는 세 가지 네임스페이스는 default, kube-system 및 kube-public입니다. 현재 Kube-public은 자주 사용되지 않습니다.

kube 네임스페이스를 그대로 두는 것이 좋은 생각이며, 특히 Google Kubernetes Engine과 같은 관리형 시스템에서는 더욱 그렇습니다. 서비스와 애플리케이션이 생성되는 장소로 "기본" 네임스페이스를 사용합니다. Kubernetes가 이를 사용하도록 즉시 구성되어 있으며 제거할 수 없다는 점을 제외하면 특별한 점은 없습니다. 이는 시작하고 성능이 낮은 시스템에 적합하지만 대규모 프로덕션 시스템에서는 기본 네임스페이스를 사용하지 않는 것이 좋습니다. 후자의 경우, 한 개발 팀은 다른 사람의 코드를 쉽게 다시 작성하고 자신도 모르게 다른 팀의 작업을 중단시킬 수 있습니다.

따라서 여러 네임스페이스를 생성하고 이를 사용하여 서비스를 관리 가능한 단위로 분할해야 합니다. 단일 명령으로 네임스페이스를 만들 수 있습니다. test라는 네임스페이스를 생성하려면 $ kubectl create 네임스페이스 테스트 명령을 사용하거나 간단히 YAML 파일을 생성하여 다른 Kubernetes 리소스처럼 사용하세요.

$ kubectl get 네임스페이스 명령을 사용하여 모든 네임스페이스를 볼 수 있습니다.

완료되면 세 개의 내장 네임스페이스와 "test"라는 새 네임스페이스가 표시됩니다. Pod를 생성하는 간단한 YAML 파일을 살펴보겠습니다. 네임스페이스에 대한 언급이 없음을 알 수 있습니다.

kubectl을 사용하여 이 파일을 실행하면 현재 활성 네임스페이스에 mypod 모듈이 생성됩니다. 이는 변경할 때까지 기본 네임스페이스가 됩니다. 리소스를 생성하려는 네임스페이스를 Kubernetes에 알리는 방법에는 두 가지가 있습니다. 첫 번째 방법은 리소스를 생성할 때 네임스페이스 플래그를 사용하는 것입니다.

두 번째 방법은 YAML 선언에 네임스페이스를 지정하는 것입니다.

YAML에 네임스페이스를 지정하면 리소스는 항상 해당 네임스페이스에 생성됩니다. 네임스페이스 플래그를 사용하는 동안 다른 네임스페이스를 사용하려고 하면 명령이 실패합니다. 이제 포드를 찾으려고 하면 찾을 수 없습니다.

이는 모든 명령이 현재 활성 네임스페이스 외부에서 실행되기 때문에 발생합니다. 포드를 찾으려면 네임스페이스 플래그를 사용해야 하지만 이는 금방 지루해집니다. 특히 자체 네임스페이스를 사용하고 모든 단일 명령에 해당 플래그를 사용하고 싶지 않은 팀의 개발자라면 더욱 그렇습니다. 이 문제를 어떻게 해결할 수 있는지 살펴보겠습니다.

기본적으로 활성 네임스페이스는 default라고 합니다. 리소스 YAML에 네임스페이스를 지정하지 않으면 모든 Kubernetes 명령이 이 활성 기본 네임스페이스를 사용합니다. 안타깝게도 kubectl을 사용하여 활성 네임스페이스를 관리하려고 하면 실패할 수 있습니다. 그러나 이 프로세스를 훨씬 쉽게 만들어주는 Kubens라는 매우 유용한 도구가 있습니다. kubens 명령을 실행하면 활성 네임스페이스가 강조 표시된 모든 네임스페이스가 표시됩니다.

활성 네임스페이스를 테스트 네임스페이스로 전환하려면 $kubens test 명령을 실행하기만 하면 됩니다. 그런 다음 $kubens 명령을 다시 실행하면 이제 새로운 활성 네임스페이스가 할당된 것을 볼 수 있습니다(test).

이는 테스트 네임스페이스에서 Pod를 보기 위해 네임스페이스 플래그가 필요하지 않음을 의미합니다.

이렇게 하면 네임스페이스가 서로 숨겨지지만 서로 격리되지는 않습니다. 한 네임스페이스의 서비스는 다른 네임스페이스의 서비스와 매우 쉽게 통신할 수 있으며 이는 종종 매우 유용합니다. 다양한 네임스페이스 간에 통신할 수 있다는 것은 개발자의 서비스가 다른 네임스페이스에 있는 다른 개발팀의 서비스와 통신할 수 있음을 의미합니다.

일반적으로 애플리케이션이 Kubernetes 서비스에 액세스하려고 하면 내장된 DNS 검색 서비스를 사용하고 애플리케이션에 서비스 이름을 지정하기만 하면 됩니다. 그러나 그렇게 하면 여러 네임스페이스에서 동일한 이름으로 서비스를 생성할 수 있으며 이는 허용되지 않습니다.

다행히 확장된 형태의 DNS 주소를 사용하면 이 문제를 쉽게 해결할 수 있습니다. Kubernetes의 서비스는 공통 DNS 템플릿을 사용하여 엔드포인트를 노출합니다. 다음과 같이 보입니다.

일반적으로 서비스 이름만 있으면 DNS가 자동으로 전체 주소를 결정합니다.

그러나 다른 네임스페이스의 서비스에 액세스해야 하는 경우 서비스 이름과 네임스페이스 이름을 사용하면 됩니다.

예를 들어 테스트 네임스페이스의 서비스 데이터베이스에 연결하려는 경우 주소 데이터베이스 데이터베이스.test를 사용할 수 있습니다.

prod 네임스페이스의 서비스 데이터베이스에 연결하려면 Database.prod를 사용합니다.

네임스페이스 액세스를 격리하고 제한하려는 경우 Kubernetes에서는 Kubernetes 네트워크 정책을 사용하여 이를 수행할 수 있습니다. 이에 대해서는 다음 에피소드에서 이야기하겠습니다.

네임스페이스를 몇 개나 만들어야 하며 어떤 목적으로 만들어야 합니까?라는 질문을 자주 받습니다. 관리되는 데이터란 무엇입니까?

네임스페이스를 너무 많이 만들면 방해가 됩니다. 그 수가 너무 적으면 해당 솔루션의 모든 이점을 잃게 됩니다. 모든 회사가 조직 구조를 만들 때 거치는 네 가지 주요 단계가 있다고 생각합니다. 프로젝트나 회사의 개발 단계에 따라 적절한 네임스페이스 전략을 채택할 수 있습니다.

당신이 5~10개의 마이크로서비스를 개발하는 소규모 팀의 일원이고 모든 개발자를 한 방에 쉽게 모을 수 있다고 상상해 보십시오. 이 상황에서는 기본 네임스페이스에서 모든 prod 서비스를 실행하는 것이 합리적입니다. 물론 유연성을 높이기 위해 prod와 dev에 별도로 2개의 네임스페이스를 사용할 수 있습니다. 그리고 Minikube와 같은 것을 사용하여 로컬 컴퓨터에서 개발을 테스트할 가능성이 높습니다.

상황이 바뀌어 한 번에 10개 이상의 마이크로서비스를 작업하는 팀이 빠르게 성장하고 있다고 가정해 보겠습니다. prod와 dev에 별도로 여러 클러스터나 네임스페이스를 사용해야 하는 때가 있습니다. 팀을 여러 하위 팀으로 나누어 각 팀이 자체 마이크로서비스를 갖고 각 팀이 자체 네임스페이스를 선택하여 소프트웨어 개발 및 릴리스 관리 프로세스를 용이하게 할 수 있습니다.

각 팀 구성원이 시스템 전체의 작동 방식에 대한 통찰력을 얻으면 다른 모든 개발자와 모든 변경 사항을 조정하는 것이 점점 더 어려워집니다. 로컬 머신에서 전체 스택을 가동하는 것은 날이 갈수록 어려워지고 있습니다.

대기업의 경우 개발자는 일반적으로 누가 정확히 무엇을 작업하고 있는지 알지 못합니다. 팀은 서비스 계약을 사용하여 통신하거나 Istio 구성 도구와 같이 네트워크를 통해 추상화 계층을 추가하는 서비스 메시 기술을 사용합니다. 전체 스택을 로컬에서 실행하는 것은 불가능하므로 Kubernetes의 Spinnaker와 같은 CD(지속적 전달) 플랫폼을 사용하는 것이 좋습니다. 따라서 모든 명령에는 반드시 고유한 네임스페이스가 필요한 지점이 옵니다. 각 팀은 개발 환경과 프로덕션 환경에 대해 여러 네임스페이스를 선택할 수도 있습니다.

마지막으로, 한 개발자 그룹이 다른 그룹의 존재조차 알지 못하는 대규모 기업가 기업이 있습니다. 이러한 회사는 일반적으로 잘 문서화된 API를 통해 상호 작용하는 타사 개발자를 고용할 수 있습니다. 이러한 각 그룹에는 여러 팀과 여러 마이크로서비스가 포함되어 있습니다. 이 경우 앞서 설명한 모든 도구를 사용해야 합니다.

프로그래머는 서비스를 수동으로 배포해서는 안 되며 서비스와 관련되지 않은 네임스페이스에 액세스해서는 안 됩니다. 이 단계에서는 잘못 구성된 애플리케이션의 "폭발 반경"을 줄이고 청구 프로세스 및 리소스 관리를 단순화하기 위해 여러 클러스터를 보유하는 것이 좋습니다.

따라서 조직에서 네임스페이스를 적절하게 사용하면 Kubernetes를 더욱 관리하기 쉽고, 제어하기 쉽고, 안전하고 유연하게 만들 수 있습니다.

Kubernetes 모범 사례. 준비 상태 및 활동성 테스트를 통해 Kubernetes 활동성 검증

일부 광고 🙂

우리와 함께있어 주셔서 감사합니다. 우리 기사가 마음에 드십니까? 더 재미있는 콘텐츠를 보고 싶다면? 주문하거나 친구에게 추천하여 우리를 지원하십시오. $4.99부터 시작하는 개발자용 클라우드 VPS, 귀하를 위해 우리가 발명한 고유한 보급형 서버 아날로그: VPS(KVM) E5-2697 v3(6코어) 10GB DDR4 480GB SSD 1Gbps에 대한 전체 진실 또는 서버 공유 방법은? (RAID1 및 RAID10에서 사용 가능, 최대 24개 코어 및 최대 40GB DDR4).

Dell R730xd는 암스테르담의 Equinix Tier IV 데이터 센터에서 2배 더 저렴합니까? 여기서 만 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199부터 네덜란드에서! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 최저 $99! 에 대해 읽다 인프라 공사를 구축하는 방법. 730페니에 5유로 상당의 Dell R2650xd E4-9000 vXNUMX 서버를 사용하는 클래스?

출처 : habr.com