k8s 세계에서는 모든 리소스가 컨트롤러를 통해 생성됩니다. 포드, 배포, 복제본 세트 등에 대한 내장형 컨트롤러가 있는 것처럼 기본적으로 컨트롤러는 클러스터 상태를 지속적으로 모니터링하고 클러스터를 원하는 상태로 만들기 위한 조치를 취하는 제어 루프일 뿐입니다. 리소스에는 원하는 상태를 제공하는 사양이 있습니다. 컨트롤러는 현재 상태를 확인합니다. 원하는 상태와 일치하지 않으면 원하는 상태에 더 가까워질 수 있도록 적절한 변경이나 수정을 가합니다.
ReplicaSet 컨트롤러: 이 컨트롤러는 언제든지 실행되는 안정적인 복제본 Pod 세트를 유지 관리하는 역할을 합니다. 이는 노드 오류 또는 Pod 종료 시에도 지정된 수의 Pod 복제본이 항상 실행되도록 배포와 함께 사용되는 경우가 많습니다.
배포 컨트롤러: 이 컨트롤러는 Pod 및 ReplicaSet에 대한 선언적 업데이트를 제공합니다. 이를 통해 애플리케이션의 손쉬운 확장, 롤링 업데이트 및 롤백이 가능합니다. 배포 컨트롤러는 원하는 수의 Pod가 항상 실행되도록 ReplicaSet의 생성 및 삭제를 관리합니다.
StatefulSet 컨트롤러: 이 컨트롤러는 데이터베이스와 같은 상태 저장 애플리케이션을 관리하는 데 사용됩니다. 이는 세트의 각 Pod에 고유한 ID(안정적인 호스트 이름)를 제공하고 이러한 Pod의 순서와 고유성을 유지합니다. 안정적인 네트워크 식별자, 안정적인 영구 스토리지, 질서 있고 점진적인 배포 및 확장이 필요할 때 특히 유용합니다.
서비스 컨트롤러: 이 컨트롤러는 일련의 포드에 대해 안정적인 IP 주소와 DNS 이름을 유지하는 역할을 합니다. 이는 로드 밸런서 역할을 하며 서비스 선택기에 따라 적절한 포드로 트래픽을 라우팅합니다. 이를 통해 서비스가 클러스터에서 생성, 삭제 또는 이동되는 경우에도 실행 중인 포드에 액세스할 수 있는 안정적인 엔드포인트를 갖게 됩니다.
따라서 테스트에 들어가기 전에 표준 컨트롤러의 기본 아키텍처를 이해해야 합니다. Kubernetes의 클라이언트-서버 아키텍처에서 컨트롤러는 Kubernetes API 서버에 대해 API 호출(주로 HTTP)을 수행하는 클라이언트로서 중요한 역할을 합니다. 주요 목표는 Kubernetes API 개체를 실제 시스템 리소스와 조정하는 것입니다. 이 아키텍처의 필수 구성 요소는 Informer를 사용하는 것입니다. 정보 제공자는 클러스터의 모든 변경 사항을 모니터링하는 역할을 담당하며, 리소스에 대한 정보를 검색하기 위한 지속적인 폴링은 API 서버의 성능을 크게 저하시킬 수 있으므로 이는 매우 중요합니다.
정보원은 리소스 데이터를 쿼리하고 이를 로컬 캐시에 저장하는 방식으로 작업합니다. 데이터가 저장되면 객체(또는 리소스)의 상태에 변화가 있을 때만 이벤트가 발생합니다. 이 접근 방식을 사용하면 불필요한 이벤트로 인해 시스템이 과부하되지 않고 관련 변경 사항이 발생할 때만 컨트롤러에 알림이 전달됩니다.
이 아키텍처의 또 다른 중요한 개념은 리소스 버전입니다. 이 버전은 쓰기 작업마다 변경되며 낙관적 동시성 제어에 사용됩니다. 이는 충돌을 피하고 시스템 전체에서 일관성을 유지하는 방식으로 리소스 업데이트가 관리되도록 보장합니다. 이러한 메커니즘을 이해하고 활용함으로써 Kubernetes 컨트롤러는 클러스터의 리소스 상태를 효율적으로 관리하고 조정할 수 있습니다.
Kubernetes에서는 사용자가 사용자 정의 리소스를 정의할 수 있는 Kubernetes API의 확장인 CRD(사용자 정의 리소스 정의)를 생성할 수 있습니다. 이러한 사용자 지정 리소스는 기본 Kubernetes 설치에서는 사용할 수 없으며 도메인별 사용 사례와 복잡한 애플리케이션 요구 사항을 수용하는 데 사용됩니다.
이러한 사용자 정의 리소스를 관리하려면 사용자 정의 컨트롤러가 필요합니다. 맞춤형 컨트롤러, CRD 및 Kubernetes API 서버는 다음과 같은 응집력 있는 관계를 형성합니다.
CRD는 사용자 정의 리소스를 정의합니다.
API 서버는 이러한 리소스의 수명주기를 관리합니다.
사용자 정의 컨트롤러는 이러한 리소스의 상태가 원하는 구성에 따라 유지되도록 보장합니다.
이 아키텍처는 Kubernetes의 확장성을 가능하게 하여 사용자가 특정 요구 사항에 맞게 플랫폼을 맞춤화할 수 있게 해줍니다.
Kubernetes 컨트롤러를 프로덕션에 배포하기 전에 Kubernetes 컨트롤러가 Kubernetes API 서버에 대한 요청을 처리할 준비가 되었는지 확인하는 것이 중요합니다. Kubernetes 컨트롤러를 테스트하는 데는 여러 가지 접근 방식이 있습니다. 제가 언급한 것 중 일부는 기사에서 발췌한 것입니다:
클라이언트 이동 가짜 또는 상위 수준 추상화 사용: 이 접근 방식은 지원 API 실행을 방지하므로 개별 구성 요소를 개별적으로 단위 테스트하는 데 적합합니다.
컨트롤러 런타임에서 envtest 패키지 사용: 이 패키지는 축소된 API 서버와 함께 작동하여 다른 컨트롤러의 간섭 없이 타이밍 및 캐시 동기화를 포함하여 API와의 실제 상호 작용을 검증합니다. . 축소된 인스턴스에 대한 로컬 테스트와 완전히 작동하는 클러스터에 대한 테스트를 모두 지원합니다.
실제 API 서버 실행: 이 접근 방식은 실제 결과를 테스트하기 위한 임시 종류 또는 microk8s와 같은 스테이징 환경이나 인스턴스에 적합합니다. 실제 API 서버에 대한 상호 작용을 테스트할 수 있습니다.
envtest나 실제 API 서버와 같은 외부 프로세스를 사용하면 분산 시스템에 내재된 대기 시간을 처리할 수 있다는 이점이 있습니다. Gomega와 같은 라이브러리는 작업이 발생한 후 특정 조건을 기다리는 데 사용할 수 있습니다. 위의 접근 방식은 특정 구성 요소를 개별적으로 테스트하는 단위 테스트 및 통합 수준 테스트에 가장 적합한 경우가 많습니다. 테스트를 작성하여 데이터를 위조하거나
위 기술은 단위 및 통합 테스트에는 효과적이지만 컨트롤러의 전체 기능을 보장하는 데 중요한 e2e(엔드 투 엔드) 테스트에는 적용되지 않을 수 있습니다. e2e 테스트에 대한 한 가지 접근 방식은 리소스 업데이트 및 기타 작업을 수행하여 통제된 환경에서 컨트롤러의 전체 흐름을 테스트하고 필요할 때마다 프로세스를 복제하는 것입니다. 이는 실제 시나리오에서 컨트롤러의 동작을 검증하고 프로덕션 배포 준비가 되었는지 확인하는 데 도움이 됩니다.
요약하자면, Kubernetes 컨트롤러를 프로덕션에 적용하기 전에 안정성과 효율성을 보장하려면 단위, 통합, 엔드투엔드 테스트의 조합이 필수적입니다.
Kubernetes 컨트롤러를 로컬에서 구축하고 테스트하는 것은 어려울 수 있으며, 특히 나가는 API 호출을 처리할 때 더욱 그렇습니다. 그러나 Keploy는 API 호출, DB 쿼리 등에서 테스트 케이스와 데이터 모의를 생성하는 도구로서 솔루션을 제공합니다. Keploy를 사용하면 Kubernetes 컨트롤러에서 이루어진 발신 호출을 기록하고 재생할 수 있으며, 이는 컨트롤러가 예상대로 작동하는지 테스트하고 확인하는 데 매우 유용할 수 있습니다.
코드 변경 없이 어떻게 이것이 가능한지 궁금하실 것입니다. Keploy는 eBPF를 사용하여 커널 공간에 프로브를 추가하고 네트워크 버퍼 데이터를 수집합니다. 그런 다음 이 데이터는 Keploy의 프록시로 전송되며, 이는 버퍼의 모든 처리가 다른 프로토콜 파서에 의해 수행되는 사용자 공간 역할을 합니다. Keploy는 컨트롤러의 송신 트래픽을 캡처하고 특정 이벤트에 대한 요청과 응답을 YAML 파일에 저장할 수 있습니다. 재생 모드에서는 실제 API 서버에 대한 API 호출을 수행하는 대신 Keploy가 해당 특정 요청에 대해 저장된 YAML 파일의 응답을 반환합니다. 이를 통해 프로세스가 클러스터나 환경과 독립적이게 되어 Kubernetes 컨트롤러를 로컬에서 테스트하는 편리하고 효율적인 방법을 제공합니다.
따라서 로컬 또는 실제 환경에서 컨트롤러 테스트를 캡처하려면 먼저 kubernetes 클러스터를 시작하고 서버와 상호 작용할 수 있는 사용자 정의 컨트롤러를 만들어야 합니다.
Keploy로 컨트롤러를 녹화하려면 다음 단계를 따르세요.
Kubernetes *rest.Config 객체를 안전하지 않고 CA 파일 없이 설정하세요.
cfg.Insecure = true cfg.CAFile = ""
리소스 버전이 포함된 헤더 필드를 추가하려면 사용자 정의 RoundTripper를 생성하세요. 이 헤더는 기록된 모의 항목과 동일한 상태 동안 요청을 일치시키기 위한 추적 ID 역할을 합니다. 구현 예는 다음과 같습니다.
type customRoundTripper struct {
rt http.RoundTripper
}
func (crt *customRoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {
ctx := req.Context()
rsv := ctx.Value("ResourceVersion")
if rsv != nil {
req.Header.Add("keploy-header", rsv.(string))
}
return crt.rt.RoundTrip(req)
}
cfg.WrapTransport = func(rt http.RoundTripper) http.RoundTripper {
return &customRoundTripper{rt: rt}
}
동기화 프로세스 중에 context.Context에 리소스 버전 값을 설정해야 합니다. 이는 수정된 컨텍스트를 컨트롤러의 업데이트 및 생성 메서드에 전달하는 데 중요합니다. 예:
func (c *Controller) syncHandler(ctx context.Context, key string) error {
// set ResourceVersion in ctx
rv := foo.GetResourceVersion()
if rv != "" {
ctx = context.WithValue(ctx, "ResourceVersion", rv)
}
}
Kubernetes 컨트롤러의 Go 바이너리를 빌드하세요.
go build -o sample-controller .
Keploy를 통해 발신 통화를 녹음하려면 컨트롤러 명령을 Keploy의 녹음 명령으로 래핑하세요. 참고 - keploy의 이 기능은 베타 버전으로 사용 중이며 아직 메인에 출시되지 않았습니다. 이는 Kubernetes 열성팬이 리뷰를 시도하고 제공할 수 있는 실험으로 특별히 만들어졌습니다. 따라서 이 특정 분기를 체크아웃하고 go build 명령을 사용하여 keploy 바이너리를 빌드해야 합니다. https://github.com/keploy/keploy/pull/1342.
지정된 지점에서 결제하세요.
1.
git checkout kube-controller
```
{% endraw %}
해당 브랜치에 대한 keploy 바이너리를 빌드합니다.
{% 원시 %}
go build -o keploy && sudo mv keploy /usr/local/bin
kube 구성에 따라 필요한 플래그를 추가하세요.
sudo -E env PATH=$PATH keploy record -c "./sample-controller -kubeconfig=$HOME/.kube/config" --mtls-cert-path "$HOME/.minikube/profiles/minikube/client.crt" --mtls-key-path "$HOME/.minikube/profiles/minikube/client.key" --mtls-host-name 192.168.49.2:8443
Keploy가 아웃바운드 통화를 가로채기 시작하자마자 keploy/test-set-0/mocks.yaml이 생성되는 것을 볼 수 있습니다. 각 리소스 버전에는 mocks_ "
참고 - 한 가지 분명히 말씀드리고 싶은 점은 위 기능이 TDD(Test Driven Development)에서는 도움이 되지 않는다는 것입니다. 그러나 keploy의 스텁 생성 기능을 활용하여 단위 테스트를 작성하는 동안에도 keploy를 사용할 수 있습니다. 따라서 모의 API 서버를 만들거나 특정 단위 테스트를 위한 스텁을 작성하는 대신 실제 환경에서 해당 테스트를 한 번 실행할 수 있습니다. Keploy는 모든 상호 작용을 모의 파일에 저장하고 다음에 테스트를 실행할 때 해당 데이터를 사용합니다.
녹화된 모의 테스트로 컨트롤러를 테스트하려면:
mockAssert 플래그를 true로 설정하고 테스트 모드에서 Keploy를 실행하고 컨트롤러 바이너리를 제공하세요. Keploy는 자동으로 가짜 kube 구성을 생성합니다.
cfg.Insecure = true cfg.CAFile = ""
선택적으로 재생 시간을 직접 설정하여 제공된 시간 내에 녹화된 세션을 재생할 수 있습니다. keploy와 통합된 전체 샘플 앱이 여기에서 제공됩니다.
type customRoundTripper struct {
rt http.RoundTripper
}
func (crt *customRoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {
ctx := req.Context()
rsv := ctx.Value("ResourceVersion")
if rsv != nil {
req.Header.Add("keploy-header", rsv.(string))
}
return crt.rt.RoundTrip(req)
}
cfg.WrapTransport = func(rt http.RoundTripper) http.RoundTripper {
return &customRoundTripper{rt: rt}
}
재생 프로세스는 충분히 큰 이벤트 시간 간격을 제보자의 두 이벤트 간의 정확한 평균 기간으로 줄입니다. 이를 통해 이벤트가 기록에서 발생한 것보다 일찍 전송될 수 있어 재생 속도가 빨라집니다.
이것은 컨트롤러에서 생성된 API 호출의 전체 세션을 재생하는 데 도움이 될 수 있지만 이번에는 응답을 얻기 위해 실제 k8s 서버나 외부 소스가 필요하지 않습니다. 모든 응답은 모의 서버나 중개인처럼 작동하는 keploy 자체에 의해 반환됩니다. 이를 통해 CI-CD 파이프라인에서 실행하는 데 자신감을 가질 수 있습니다.
예를 들어 - 대규모 클라우드 컴퓨팅 조직에서 일하고 모든 것을 배포하려면 많은 가상화가 필요하며 리소스 집약적인 작업입니다. 그래서 실제 환경에서 테스트하는 것은 거의 불가능합니다. 여기서 Keploy와 같은 도구는 해당 리소스가 성공적으로 출시될 경우 얻고자 하는 응답을 이미 갖고 있으므로 매우 유용할 수 있습니다. 따라서 컨트롤러 서비스의 올바른 흐름을 단 한 번만 캡처하면 빠르고 안정적이며 비용을 절감할 수 있습니다. 그리고 후속 릴리스에서 keploy 재생을 재사용할 수 있습니다.
Keploy와 같은 도구를 사용하면 Kubernetes 컨트롤러를 로컬에서 더욱 효율적이고 안정적으로 테스트할 수 있습니다. 발신 호출을 녹음하고 재생하면 컨트롤러가 다양한 시나리오에서 올바르게 작동하는지 확인하여 Kubernetes 애플리케이션의 전반적인 품질을 향상시킬 수 있습니다. keploy는 gotest와 같은 테스트 프레임워크를 기본적으로 지원하므로 kube 컨트롤러를 포함한 모든 애플리케이션의 라인 적용 범위를 얻는 것도 가능합니다. Keploy를 살펴보고 Kubernetes 컨트롤러 테스트 워크플로를 강화하세요!
발신 API 호출 기록 및 재생: 이렇게 하면 테스트 중에 라이브 환경이 필요하지 않습니다.
효율성 향상: 저장된 모의 항목을 사용하면 테스트 속도가 빨라지고 실제 Kubernetes 클러스터와 독립적이게 됩니다.
비용 및 리소스 절약: 검증을 위해 리소스 집약적인 환경에 대한 의존도를 줄여 대규모 작업의 CI/CD 파이프라인에 이상적입니다.
Keploy는 eBPF 프로브를 사용하여 발신 전화를 가로채고 요청-응답 쌍을 모의 파일에 저장합니다. 재생 모드 중:
전화를 가로채서 이전에 녹음된 모의와 연결합니다.
실제 API 서버에 연결하는 대신 이러한 모의 개체에서 응답이 반환됩니다.
이 메커니즘을 통해 라이브 Kubernetes 클러스터 없이도 테스트를 실행할 수 있습니다.
Keploy의 녹음 및 재생 기능은 TDD용으로 특별히 설계되지는 않았지만 여전히 효과적으로 사용할 수 있습니다.
스텁 생성: 실제 환경에서 컨트롤러를 한 번 실행하여 상호 작용을 캡처합니다. Keploy는 이후 사용을 위해 모형을 생성합니다.
단위 테스트 지원: 이러한 모의를 활용하면 스텁을 수동으로 작성하지 않고 테스트 실행에 집중할 수 있습니다.
Keploy는 모의 생성을 간소화하고 개발 오버헤드를 줄여 기존 TDD 워크플로를 보완합니다.
위 내용은 사용자 정의 Kubernetes 컨트롤러를 사용하여 트래픽을 테스트하는 방법: 단계별 가이드의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
