Kubernetes 클러스터에서 오래된 기능 분기 제거

Привет! 기능 분기 (미리보기 배포, 앱 검토라고도 함) - 이는 마스터 브랜치뿐만 아니라 고유한 URL에 대한 각 끌어오기 요청도 배포되는 경우입니다. 코드가 프로덕션 환경에서 작동하는지 확인할 수 있으며, 해당 기능을 다른 프로그래머나 제품 전문가에게 보여줄 수 있습니다. 끌어오기 요청 작업을 하는 동안 이전 코드에 대한 각각의 새로운 커밋 현재 배포가 삭제되고 새 코드에 대한 새 배포가 롤아웃됩니다. 풀 요청을 마스터 브랜치에 병합할 때 질문이 발생할 수 있습니다. 더 이상 기능 분기가 필요하지 않지만 Kubernetes 리소스는 여전히 클러스터에 있습니다.

기능 분기에 대한 추가 정보

Kubernetes에서 기능 분기를 만드는 한 가지 접근 방식은 네임스페이스를 사용하는 것입니다. 간단히 말해서 프로덕션 구성은 다음과 같습니다.

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end
spec:
  replicas: 3
...

기능 브랜치의 경우 식별자(예: 풀 요청 번호)와 일종의 접두사/접미사(예: -pr-):

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end-pr-17
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end-pr-17
spec:
  replicas: 1
...

일반적으로 나는 썼다. 쿠버네티스 오퍼레이터 (클러스터 리소스에 액세스할 수 있는 애플리케이션) Github의 프로젝트 링크. 이전 기능 분기에 속한 네임스페이스를 제거합니다. Kubernetes에서는 네임스페이스를 삭제하면 해당 네임스페이스의 다른 리소스도 자동으로 삭제됩니다.

$ kubectl get pods --all-namespaces | grep -e "-pr-"
NAMESPACE            ... AGE
habr-back-end-pr-264 ... 4d8h
habr-back-end-pr-265 ... 5d7h

클러스터에 기능 분기를 구현하는 방법에 대해 읽을 수 있습니다. 여기에 и 여기에.

자극

지속적인 통합이 포함된 일반적인 풀 요청 수명 주기를 살펴보겠습니다(continuous integration):

1. 우리는 브랜치에 새로운 커밋을 푸시합니다.
2. 빌드에서는 린터 및/또는 테스트가 실행됩니다.
3. Kubernetes 풀 요청 구성은 즉시 생성됩니다(예를 들어 해당 번호는 완성된 템플릿에 삽입됩니다).
4. kubectl apply를 사용하면 클러스터에 구성이 추가됩니다(배포).
5. 풀 요청이 마스터 브랜치에 병합됩니다.

끌어오기 요청 작업을 하는 동안 이전 코드에 대한 각각의 새로운 커밋 현재 배포가 삭제되고 새 코드에 대한 새 배포가 롤아웃됩니다. 그러나 풀 요청이 마스터 브랜치에 병합되면 마스터 브랜치만 빌드됩니다. 결과적으로 우리는 이미 풀 요청을 잊어버렸으며 해당 Kubernetes 리소스는 여전히 클러스터에 있다는 것이 밝혀졌습니다.

사용 방법

아래 명령을 사용하여 프로젝트를 설치합니다.

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml

다음 내용으로 파일을 생성하고 다음을 통해 설치하십시오. kubectl apply -f:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 3

매개 변수 네임스페이스하위 문자열 다른 네임스페이스의 풀 요청에 대한 네임스페이스를 필터링하는 데 필요합니다. 예를 들어 클러스터에 다음과 같은 네임스페이스가 있는 경우: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33이면 삭제 후보는 다음과 같습니다. habr-back-end-pr-17, habr-back-end-pr-33.

매개 변수 afterDaysWithoutDeploy 이전 네임스페이스를 삭제하는 데 필요합니다. 예를 들어 네임스페이스가 생성된 경우 3 дня 1 час 뒤로, 매개변수는 다음을 나타냅니다. 3 дня, 이 네임스페이스는 삭제됩니다. 네임스페이스가 생성되면 반대 방향으로도 작동합니다. 2 дня 23 часа 뒤로, 매개변수는 다음을 나타냅니다. 3 дня, 이 네임스페이스는 삭제되지 않습니다.

매개변수가 하나 더 있습니다. 모든 네임스페이스를 스캔하고 배포하지 않은 기간을 확인하는 빈도를 담당합니다. 매분 확인. 기본적으로는 동일합니다. 30 минутам.

이거 어떻게 작동 시켜요

실제로는 다음이 필요합니다.

1. 도커 고립된 환경에서 작업하기 위해
2. 미니쿠베 Kubernetes 클러스터를 로컬로 생성합니다.
3. 쿠 베틀 — 클러스터 관리를 위한 명령줄 인터페이스입니다.

Kubernetes 클러스터를 로컬에서 생성합니다.

$ minikube start --vm-driver=docker
minikube v1.11.0 on Darwin 10.15.5
Using the docker driver based on existing profile.
Starting control plane node minikube in cluster minikube.

지정 kubectl 기본적으로 로컬 클러스터를 사용합니다.

$ kubectl config use-context minikube
Switched to context "minikube".

프로덕션 환경에 대한 구성을 다운로드합니다.

$ curl https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml > stale-feature-branch-production-configs.yml

프로덕션 구성은 이전 네임스페이스를 확인하도록 구성되어 있지만 새로 생성된 클러스터에는 해당 네임스페이스가 없으므로 환경 변수를 교체합니다. IS_DEBUG 에 true. 이 값을 사용하면 매개변수 afterDaysWithoutDeploy 배포하지 않은 날 동안은 고려되지 않으며 네임스페이스는 확인되지 않으며 하위 문자열(-pr-).

켜져 있는 경우 Linux:

$ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml

켜져 있는 경우 macOS:

$ sed -i "" 's|false|true|g' stale-feature-branch-production-configs.yml

프로젝트 설치:

$ kubectl apply -f stale-feature-branch-production-configs.yml

클러스터에 리소스가 나타나는지 확인 StaleFeatureBranch:

$ kubectl api-resources | grep stalefeaturebranches
NAME                 ... APIGROUP                             ... KIND
stalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch

클러스터에 연산자가 나타나는지 확인합니다.

$ kubectl get pods --namespace stale-feature-branch-operator
NAME                                           ... STATUS  ... AGE
stale-feature-branch-operator-6bfbfd4df8-m7sch ... Running ... 38s

로그를 보면 리소스를 처리할 준비가 된 것입니다. StaleFeatureBranch:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Operator Version: 0.0.1"}
...
... "msg":"Starting EventSource", ... , "source":"kind source: /, Kind="}
... "msg":"Starting Controller", ...}
... "msg":"Starting workers", ..., "worker count":1}

기성품을 설치합니다 fixtures (클러스터 리소스 모델링을 위해 미리 만들어진 구성) StaleFeatureBranch:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/stale-feature-branch.yml

구성은 하위 문자열이 있는 네임스페이스를 검색하도록 나타냅니다. -pr- 한번에 1 минуту.:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 1 
  checkEveryMinutes: 1

운영자가 응답했으며 네임스페이스를 확인할 준비가 되었습니다.

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Stale feature branch is being processing.","namespaceSubstring":"-pr-","afterDaysWithoutDeploy":1,"checkEveryMinutes":1,"isDebug":"true"}

세트 fixtures, 두 개의 네임스페이스를 포함합니다(project-pr-1, project-pr-2) 그리고 그들 deployments, services, ingress, 등등:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/first-feature-branch.yml -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/second-feature-branch.yml
...
namespace/project-pr-1 created
deployment.apps/project-pr-1 created
service/project-pr-1 created
horizontalpodautoscaler.autoscaling/project-pr-1 created
secret/project-pr-1 created
configmap/project-pr-1 created
ingress.extensions/project-pr-1 created
namespace/project-pr-2 created
deployment.apps/project-pr-2 created
service/project-pr-2 created
horizontalpodautoscaler.autoscaling/project-pr-2 created
secret/project-pr-2 created
configmap/project-pr-2 created
ingress.extensions/project-pr-2 created

위의 모든 리소스가 성공적으로 생성되었는지 확인합니다.

$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...
NAME                              ... READY ... STATUS  ... AGE
pod/project-pr-1-848d5fdff6-rpmzw ... 1/1   ... Running ... 67s

NAME                         ... READY ... AVAILABLE ... AGE
deployment.apps/project-pr-1 ... 1/1   ... 1         ... 67s
...

우리가 포함했기 때문에 debug, 네임스페이스 project-pr-1 и project-pr-2따라서 다른 모든 리소스는 매개변수를 고려하지 않고 즉시 삭제되어야 합니다. afterDaysWithoutDeploy. 이는 운영자 로그에서 확인할 수 있습니다.

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-1"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-1","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-1"}
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-2"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-2","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-2"}

자원의 가용성을 확인하면 상태가 됩니다. Terminating (삭제 프로세스) 또는 이미 삭제되었습니다(명령 출력이 비어 있음).

$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...

생성 과정을 반복할 수 있습니다. fixtures 여러 번 반복하고 XNUMX분 이내에 제거되었는지 확인하십시오.

대안

클러스터에서 일하는 운영자 대신 무엇을 할 수 있나요? 여러 가지 접근 방식이 있으며 모두 불완전하며(단점은 주관적임) 모든 사람이 특정 프로젝트에 가장 적합한 것이 무엇인지 스스로 결정합니다.

1. 마스터 브랜치의 지속적인 통합 빌드 중에 기능 브랜치를 삭제합니다.

   • 이렇게 하려면 빌드 중인 커밋과 관련된 풀 요청이 무엇인지 알아야 합니다. 기능 브랜치 네임스페이스에는 풀 요청 식별자(해당 번호 또는 브랜치 이름)가 포함되어 있으므로 식별자는 항상 커밋에 지정되어야 합니다.
   • 마스터 브랜치 빌드가 실패합니다. 예를 들어 프로젝트 다운로드, 테스트 실행, 프로젝트 빌드, 릴리스 만들기, 알림 보내기, 마지막 끌어오기 요청의 기능 분기 지우기 등의 단계가 있습니다. 알림을 보낼 때 빌드가 실패하면 클러스터의 모든 리소스를 수동으로 삭제해야 합니다.
   • 적절한 컨텍스트가 없으면 마스터 빌드에서 기능 분기를 삭제하는 것이 명확하지 않습니다.

2. 웹훅 사용(예).

   • 이것은 귀하의 접근 방식이 아닐 수도 있습니다. 예를 들어, 젠킨스, 한 가지 유형의 파이프라인만이 해당 구성을 소스 코드에 저장하는 기능을 지원합니다. 웹후크를 사용할 때 이를 처리하려면 자체 스크립트를 작성해야 합니다. 이 스크립트는 유지 관리가 어려운 Jenkins 인터페이스에 배치되어야 합니다.

3. 쓰기 크론잡 Kubernetes 클러스터를 추가합니다.

   • 글쓰기와 지원에 시간을 보냅니다.
   • 운영자는 이미 유사한 스타일로 작업하고 문서화되어 지원됩니다.

기사에 관심을 가져 주셔서 감사합니다. Github의 프로젝트 링크.

출처 : habr.com