InfoGrab Docs

Kubernetes 배포 시작하기

요약

이 페이지에서는 GitLab이 지원하는 방법을 사용하여 Kubernetes에 배포하는 방법을 소개합니다. 이 튜토리얼은 Kubernetes 클러스터를 GitLab에 연결하기 시작하기에서 생성한 프로젝트를 기반으로 합니다.

이 페이지에서는 GitLab이 지원하는 방법을 사용하여 Kubernetes에 배포하는 방법을 소개합니다. 마지막에는 다음을 이해하게 됩니다:

  • Flux로 배포하는 방법
  • GitLab CI/CD 파이프라인에서 클러스터에 대해 명령을 실행하거나 배포하는 방법
  • 최상의 결과를 위해 Flux와 GitLab CI/CD를 결합하는 방법

시작하기 전에#

이 튜토리얼은 Kubernetes 클러스터를 GitLab에 연결하기 시작하기에서 생성한 프로젝트를 기반으로 합니다. 해당 튜토리얼에서 생성한 동일한 프로젝트를 사용합니다. 그러나 연결된 Kubernetes 클러스터와 부트스트랩된 Flux 설치가 있는 모든 프로젝트를 사용할 수 있습니다.

GitLab CI/CD에서 클러스터에 대해 명령 실행#

Kubernetes용 에이전트는 GitLab CI/CD 파이프라인과 통합됩니다. CI/CD를 사용하여 안전하고 확장 가능한 방식으로 클러스터에 대해 kubectl apply 및 helm upgrade 같은 명령을 실행할 수 있습니다.

이 섹션에서는 GitLab 파이프라인 통합을 사용하여 클러스터에서 시크릿을 생성하고 GitLab 컨테이너 레지스트리에 접근하는 데 사용합니다. 이 튜토리얼의 나머지 부분에서는 배포된 시크릿을 사용합니다.

  1. read_registry 범위로 배포 토큰 생성.

  2. 배포 토큰과 사용자 이름을 CONTAINER_REGISTRY_ACCESS_TOKEN 및 CONTAINER_REGISTRY_ACCESS_USERNAME이라는 CI/CD 변수로 저장합니다.

    • 두 변수 모두 환경을 container-registry-secret*으로 설정합니다.
    • CONTAINER_REGISTRY_ACCESS_TOKEN의 경우:

  3. .gitlab-ci.yml 파일에 다음 스니펫을 추가하고 두 AGENT_KUBECONTEXT 변수를 프로젝트 경로와 일치하도록 업데이트합니다:

    stages:
- setup
- deploy
- stop

create-registry-secret:
  stage: setup
  image: "portainer/kubectl-shell:latest"
  variables:
    AGENT_KUBECONTEXT: my-group/optional-subgroup/my-repository:testing
  before_script:
    # The available agents are automatically injected into the runner environment
    # You need to select the agent to use
    - kubectl config use-context $AGENT_KUBECONTEXT
  script:
    - kubectl delete secret gitlab-registry-auth -n flux-system --ignore-not-found
    - kubectl create secret docker-registry gitlab-registry-auth -n flux-system
      --docker-password="${CONTAINER_REGISTRY_ACCESS_TOKEN}" --docker-username="${CONTAINER_REGISTRY_ACCESS_USERNAME}" --docker-server="${CI_REGISTRY}"
  environment:
    name: container-registry-secret
    on_stop: delete-registry-secret

delete-registry-secret:
  stage: stop
  image: ""
  variables:
    AGENT_KUBECONTEXT: my-group/optional-subgroup/my-repository:testing
  before_script:
    # The available agents are automatically injected into the runner environment
    # You need to select the agent to use
    - kubectl config use-context $AGENT_KUBECONTEXT
  script:
    - kubectl delete secret -n flux-system gitlab-registry-auth
  environment:
    name: container-registry-secret
    action: stop
  when: manual

계속하기 전에 CI/CD로 다른 명령을 실행하는 방법을 생각해보세요.

단순 매니페스트를 OCI 이미지로 빌드하고 클러스터에 배포#

프로덕션 사용 사례의 경우, Git 저장소와 FluxCD 사이의 캐싱 레이어로 OCI 저장소를 사용하는 것이 모범 사례입니다. FluxCD는 OCI 저장소에서 새 이미지를 확인하고, GitLab 파이프라인은 Flux 호환 OCI 이미지를 빌드합니다. 엔터프라이즈 모범 사례에 대한 자세한 내용은 엔터프라이즈 고려 사항을 참조하세요.

이 섹션에서는 단순한 Kubernetes 매니페스트를 OCI 아티팩트로 빌드한 다음 클러스터에 배포합니다.

  1. 다음 flux CLI 명령을 실행하여 Flux에게 지정된 OCI 이미지를 검색하고 내용을 배포할 위치를 알립니다. GitLab 인스턴스의 --url 값을 조정합니다. 컨테이너 레지스트리 URL은 배포 > 컨테이너 레지스트리에서 찾을 수 있습니다. 생성된 clusters/testing/nginx.yaml 파일을 검사하여 Flux가 배포할 매니페스트를 찾는 방법을 더 잘 이해할 수 있습니다.

    flux create source oci nginx-example \
 --url oci://registry.gitlab.example.org/my-group/optional-subgroup/my-repository/nginx-example \
 --tag latest \
 --secret-ref gitlab-registry-auth \
 --interval 1m \
 --namespace flux-system \
 --export > clusters/testing/nginx.yaml
 flux create kustomization nginx-example \
 --source OCIRepository/nginx-example \
 --path "." \
 --prune true \
 --target-namespace default \
 --interval 1m \
 --namespace flux-system \
 --export >> clusters/testing/nginx.yaml

  2. 예시로 NGINX를 배포합니다. 다음 YAML을 clusters/applications/nginx/nginx.yaml에 추가합니다:

     apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: nginx-example
   namespace: default
 spec:
   replicas: 1
   selector:
     matchLabels:
       app: nginx-example
   template:
     metadata:
       labels:
         app: nginx-example
     spec:
       containers:
         - name: nginx
           image: nginx:1.25
           ports:
             - containerPort: 80
               protocol: TCP
 ---
 apiVersion: v1
 kind: Service
 metadata:
   name: nginx-example
   namespace: default
 spec:
   ports:
     - port: 80
       targetPort: 80
       protocol: TCP
   selector:
     app: nginx-example

  3. 이제 이전 YAML을 OCI 이미지로 패키징합니다. AGENT_KUBECONTEXT 변수를 업데이트하여 .gitlab-ci.yml 파일을 다음 스니펫으로 확장합니다:

     nginx-deployment:
     stage: deploy
     variables:
         IMAGE_NAME: nginx-example   # Image name to push
         IMAGE_TAG: latest
         MANIFEST_PATH: "./clusters/applications/nginx"
         IMAGE_TITLE: NGINX example   # Image title to use in OCI annotation
         AGENT_KUBECONTEXT: my-group/optional-subgroup/my-repository:testing
         FLUX_OCI_REPO_NAME: nginx-example  # Flux OCIRepository to reconcile
         NAMESPACE: flux-system  # Namespace for the OCIRepository resource
     # This section configures a GitLab environment for the nginx deployment specifically
     environment:
         name: applications/nginx
         kubernetes:
             agent: $AGENT_KUBECONTEXT
             dashboard:
               namespace: default
               flux_resource_path: kustomize.toolkit.fluxcd.io/v1/namespaces/flux-system/kustomizations/nginx-example  # You will deploy this resource in the next step
     image:
         name: "fluxcd/flux-cli:v2.4.0"
         entrypoint: [""]
     before_script:
         - kubectl config use-context $AGENT_KUBECONTEXT
     script:
         # This line builds and pushes the OCI container to the GitLab container registry.
         # You can read more about this command in https://fluxcd.io/flux/cmd/flux_push_artifact/
         - flux push artifact oci://${CI_REGISTRY_IMAGE}/${IMAGE_NAME}:${IMAGE_TAG}
             --source="${CI_REPOSITORY_URL}"
             --path="${MANIFEST_PATH}"
             --revision="${CI_COMMIT_SHORT_SHA}"
             --creds="${CI_REGISTRY_USER}:${CI_REGISTRY_PASSWORD}"
             --annotations="org.opencontainers.image.url=${CI_PROJECT_URL}"
             --annotations="org.opencontainers.image.title=${IMAGE_TITLE}"
             --annotations="com.gitlab.job.id=${CI_JOB_ID}"
             --annotations="com.gitlab.job.url=${CI_JOB_URL}"
         # This line triggers an immediate reconciliation of the resource. Otherwise Flux would reconcile following its configured reconciliation period.
         # You can read more about the various reconcile commands in https://fluxcd.io/flux/cmd/flux_reconcile/
         - flux reconcile source oci -n ${NAMESPACE} ${FLUX_OCI_REPO_NAME}

  4. 변경 사항을 커밋하고 프로젝트에 푸시하고 빌드 파이프라인이 완료될 때까지 기다립니다.

  5. 왼쪽 사이드바에서 운영 > 환경을 선택하고 사용 가능한 Kubernetes 대시보드를 확인합니다. applications/nginx 환경이 정상이어야 합니다.

GitLab 파이프라인 접근 보안#

이전에 배포된 에이전트는 .gitlab/agents/testing/config.yaml 파일을 사용하여 구성됩니다. 기본적으로 구성은 GitLab 파이프라인이 실행되는 프로젝트에 구성된 클러스터에 대한 접근을 활성화합니다. 기본적으로 이 접근은 배포된 에이전트의 서비스 계정을 사용하여 클러스터에 대해 명령을 실행합니다. 이 접근은 정적 서비스 계정 ID로 제한하거나 클러스터에서 ID로 CI/CD 작업을 사용하여 제한할 수 있습니다. 마지막으로 일반 Kubernetes RBAC를 사용하여 클러스터에서 CI/CD 작업의 접근을 제한할 수 있습니다.

이 섹션에서는 모든 CI/CD 작업에 ID를 추가하고 클러스터에서 작업을 가장하여 CI/CD 접근을 제한하는 방법을 보여줍니다.

  1. CI/CD 작업 가장을 구성하려면 .gitlab/agents/testing/config.yaml 파일을 편집하고 다음 스니펫을 추가합니다(path/to/project를 교체):

    ci_access:
   projects:
      - id: my-group/optional-subgroup/my-repository
        access_as:
           ci_job: {}

  2. CI/CD 작업에 아직 클러스터 바인딩이 없으므로 GitLab CI/CD에서 Kubernetes 명령을 실행할 수 없습니다. CI/CD 작업이 flux-system 네임스페이스에서 Secret 객체를 생성할 수 있도록 활성화합니다. 다음 내용으로 clusters/testing/gitlab-ci-job-secret-write.yaml 파일을 생성합니다:

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
   name: secret-manager
   namespace: default
rules:
   - apiGroups: [""]
     resources: ["secrets"]
     verbs: ["create", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
   name: gitlab-ci-secrets-binding
   namespace: default
subjects:
   - kind: Group
     name: gitlab:ci_job
     apiGroup: rbac.authorization.k8s.io
roleRef:
   kind: Role
   name: secret-manager
   apiGroup: rbac.authorization.k8s.io

  3. CI/CD 작업이 FluxCD 조정도 트리거할 수 있도록 활성화합니다. 다음 내용으로 clusters/testing/gitlab-ci-job-flux-reconciler.yaml 파일을 생성합니다:

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
    name: ci-job-admin
roleRef:
    name: flux-edit-flux-system
    kind: ClusterRole
    apiGroup: rbac.authorization.k8s.io
subjects:
    - name: gitlab:ci_job
      kind: Group
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
    name: ci-job-view
roleRef:
    name: flux-view-flux-system
    kind: ClusterRole
    apiGroup: rbac.authorization.k8s.io
subjects:
    - name: gitlab:ci_job
      kind: Group

CI/CD 접근에 대한 자세한 내용은 Kubernetes 클러스터와 GitLab CI/CD 사용을 참조하세요.

리소스 정리#

완료하려면 배포된 리소스를 제거하고 컨테이너 레지스트리에 접근하는 데 사용한 시크릿을 삭제합니다:

  1. clusters/testing/nginx.yaml 파일을 삭제합니다. Flux가 클러스터에서 관련 리소스를 제거합니다.
  2. container-registry-secret 환경을 중지합니다. 환경 중지는 on_stop 작업을 트리거하여 클러스터에서 시크릿을 제거합니다.

다음 단계#

이 튜토리얼의 기법을 사용하여 프로젝트 간에 배포를 확장할 수 있습니다. OCI 이미지는 다른 프로젝트에서 빌드할 수 있으며 Flux가 올바른 레지스트리를 가리키는 한 Flux가 검색합니다. 이 연습은 독자를 위해 남겨둡니다.

더 많은 연습을 위해 /clusters/testing/flux-system/gotk-sync.yaml의 원래 Flux GitRepository를 OCIRepository로 변경해보세요.

마지막으로 Flux와 Kubernetes와의 GitLab 통합에 대한 자세한 내용은 다음 리소스를 참조하세요:

Kubernetes 배포 시작하기

Tier: Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
원문 보기
요약

이 페이지에서는 GitLab이 지원하는 방법을 사용하여 Kubernetes에 배포하는 방법을 소개합니다. 이 튜토리얼은 Kubernetes 클러스터를 GitLab에 연결하기 시작하기에서 생성한 프로젝트를 기반으로 합니다.

이 페이지에서는 GitLab이 지원하는 방법을 사용하여 Kubernetes에 배포하는 방법을 소개합니다. 마지막에는 다음을 이해하게 됩니다:

  • Flux로 배포하는 방법
  • GitLab CI/CD 파이프라인에서 클러스터에 대해 명령을 실행하거나 배포하는 방법
  • 최상의 결과를 위해 Flux와 GitLab CI/CD를 결합하는 방법

시작하기 전에#

이 튜토리얼은 Kubernetes 클러스터를 GitLab에 연결하기 시작하기에서 생성한 프로젝트를 기반으로 합니다. 해당 튜토리얼에서 생성한 동일한 프로젝트를 사용합니다. 그러나 연결된 Kubernetes 클러스터와 부트스트랩된 Flux 설치가 있는 모든 프로젝트를 사용할 수 있습니다.

GitLab CI/CD에서 클러스터에 대해 명령 실행#

Kubernetes용 에이전트는 GitLab CI/CD 파이프라인과 통합됩니다. CI/CD를 사용하여 안전하고 확장 가능한 방식으로 클러스터에 대해 kubectl apply 및 helm upgrade 같은 명령을 실행할 수 있습니다.

이 섹션에서는 GitLab 파이프라인 통합을 사용하여 클러스터에서 시크릿을 생성하고 GitLab 컨테이너 레지스트리에 접근하는 데 사용합니다. 이 튜토리얼의 나머지 부분에서는 배포된 시크릿을 사용합니다.

  1. read_registry 범위로 배포 토큰 생성.

  2. 배포 토큰과 사용자 이름을 CONTAINER_REGISTRY_ACCESS_TOKEN 및 CONTAINER_REGISTRY_ACCESS_USERNAME이라는 CI/CD 변수로 저장합니다.

    • 두 변수 모두 환경을 container-registry-secret*으로 설정합니다.
    • CONTAINER_REGISTRY_ACCESS_TOKEN의 경우:

  3. .gitlab-ci.yml 파일에 다음 스니펫을 추가하고 두 AGENT_KUBECONTEXT 변수를 프로젝트 경로와 일치하도록 업데이트합니다:

    stages:
- setup
- deploy
- stop

create-registry-secret:
  stage: setup
  image: "portainer/kubectl-shell:latest"
  variables:
    AGENT_KUBECONTEXT: my-group/optional-subgroup/my-repository:testing
  before_script:
    # The available agents are automatically injected into the runner environment
    # You need to select the agent to use
    - kubectl config use-context $AGENT_KUBECONTEXT
  script:
    - kubectl delete secret gitlab-registry-auth -n flux-system --ignore-not-found
    - kubectl create secret docker-registry gitlab-registry-auth -n flux-system
      --docker-password="${CONTAINER_REGISTRY_ACCESS_TOKEN}" --docker-username="${CONTAINER_REGISTRY_ACCESS_USERNAME}" --docker-server="${CI_REGISTRY}"
  environment:
    name: container-registry-secret
    on_stop: delete-registry-secret

delete-registry-secret:
  stage: stop
  image: ""
  variables:
    AGENT_KUBECONTEXT: my-group/optional-subgroup/my-repository:testing
  before_script:
    # The available agents are automatically injected into the runner environment
    # You need to select the agent to use
    - kubectl config use-context $AGENT_KUBECONTEXT
  script:
    - kubectl delete secret -n flux-system gitlab-registry-auth
  environment:
    name: container-registry-secret
    action: stop
  when: manual

계속하기 전에 CI/CD로 다른 명령을 실행하는 방법을 생각해보세요.

단순 매니페스트를 OCI 이미지로 빌드하고 클러스터에 배포#

프로덕션 사용 사례의 경우, Git 저장소와 FluxCD 사이의 캐싱 레이어로 OCI 저장소를 사용하는 것이 모범 사례입니다. FluxCD는 OCI 저장소에서 새 이미지를 확인하고, GitLab 파이프라인은 Flux 호환 OCI 이미지를 빌드합니다. 엔터프라이즈 모범 사례에 대한 자세한 내용은 엔터프라이즈 고려 사항을 참조하세요.

이 섹션에서는 단순한 Kubernetes 매니페스트를 OCI 아티팩트로 빌드한 다음 클러스터에 배포합니다.

  1. 다음 flux CLI 명령을 실행하여 Flux에게 지정된 OCI 이미지를 검색하고 내용을 배포할 위치를 알립니다. GitLab 인스턴스의 --url 값을 조정합니다. 컨테이너 레지스트리 URL은 배포 > 컨테이너 레지스트리에서 찾을 수 있습니다. 생성된 clusters/testing/nginx.yaml 파일을 검사하여 Flux가 배포할 매니페스트를 찾는 방법을 더 잘 이해할 수 있습니다.

    flux create source oci nginx-example \
 --url oci://registry.gitlab.example.org/my-group/optional-subgroup/my-repository/nginx-example \
 --tag latest \
 --secret-ref gitlab-registry-auth \
 --interval 1m \
 --namespace flux-system \
 --export > clusters/testing/nginx.yaml
 flux create kustomization nginx-example \
 --source OCIRepository/nginx-example \
 --path "." \
 --prune true \
 --target-namespace default \
 --interval 1m \
 --namespace flux-system \
 --export >> clusters/testing/nginx.yaml

  2. 예시로 NGINX를 배포합니다. 다음 YAML을 clusters/applications/nginx/nginx.yaml에 추가합니다:

     apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: nginx-example
   namespace: default
 spec:
   replicas: 1
   selector:
     matchLabels:
       app: nginx-example
   template:
     metadata:
       labels:
         app: nginx-example
     spec:
       containers:
         - name: nginx
           image: nginx:1.25
           ports:
             - containerPort: 80
               protocol: TCP
 ---
 apiVersion: v1
 kind: Service
 metadata:
   name: nginx-example
   namespace: default
 spec:
   ports:
     - port: 80
       targetPort: 80
       protocol: TCP
   selector:
     app: nginx-example

  3. 이제 이전 YAML을 OCI 이미지로 패키징합니다. AGENT_KUBECONTEXT 변수를 업데이트하여 .gitlab-ci.yml 파일을 다음 스니펫으로 확장합니다:

     nginx-deployment:
     stage: deploy
     variables:
         IMAGE_NAME: nginx-example   # Image name to push
         IMAGE_TAG: latest
         MANIFEST_PATH: "./clusters/applications/nginx"
         IMAGE_TITLE: NGINX example   # Image title to use in OCI annotation
         AGENT_KUBECONTEXT: my-group/optional-subgroup/my-repository:testing
         FLUX_OCI_REPO_NAME: nginx-example  # Flux OCIRepository to reconcile
         NAMESPACE: flux-system  # Namespace for the OCIRepository resource
     # This section configures a GitLab environment for the nginx deployment specifically
     environment:
         name: applications/nginx
         kubernetes:
             agent: $AGENT_KUBECONTEXT
             dashboard:
               namespace: default
               flux_resource_path: kustomize.toolkit.fluxcd.io/v1/namespaces/flux-system/kustomizations/nginx-example  # You will deploy this resource in the next step
     image:
         name: "fluxcd/flux-cli:v2.4.0"
         entrypoint: [""]
     before_script:
         - kubectl config use-context $AGENT_KUBECONTEXT
     script:
         # This line builds and pushes the OCI container to the GitLab container registry.
         # You can read more about this command in https://fluxcd.io/flux/cmd/flux_push_artifact/
         - flux push artifact oci://${CI_REGISTRY_IMAGE}/${IMAGE_NAME}:${IMAGE_TAG}
             --source="${CI_REPOSITORY_URL}"
             --path="${MANIFEST_PATH}"
             --revision="${CI_COMMIT_SHORT_SHA}"
             --creds="${CI_REGISTRY_USER}:${CI_REGISTRY_PASSWORD}"
             --annotations="org.opencontainers.image.url=${CI_PROJECT_URL}"
             --annotations="org.opencontainers.image.title=${IMAGE_TITLE}"
             --annotations="com.gitlab.job.id=${CI_JOB_ID}"
             --annotations="com.gitlab.job.url=${CI_JOB_URL}"
         # This line triggers an immediate reconciliation of the resource. Otherwise Flux would reconcile following its configured reconciliation period.
         # You can read more about the various reconcile commands in https://fluxcd.io/flux/cmd/flux_reconcile/
         - flux reconcile source oci -n ${NAMESPACE} ${FLUX_OCI_REPO_NAME}

  4. 변경 사항을 커밋하고 프로젝트에 푸시하고 빌드 파이프라인이 완료될 때까지 기다립니다.

  5. 왼쪽 사이드바에서 운영 > 환경을 선택하고 사용 가능한 Kubernetes 대시보드를 확인합니다. applications/nginx 환경이 정상이어야 합니다.

GitLab 파이프라인 접근 보안#

이전에 배포된 에이전트는 .gitlab/agents/testing/config.yaml 파일을 사용하여 구성됩니다. 기본적으로 구성은 GitLab 파이프라인이 실행되는 프로젝트에 구성된 클러스터에 대한 접근을 활성화합니다. 기본적으로 이 접근은 배포된 에이전트의 서비스 계정을 사용하여 클러스터에 대해 명령을 실행합니다. 이 접근은 정적 서비스 계정 ID로 제한하거나 클러스터에서 ID로 CI/CD 작업을 사용하여 제한할 수 있습니다. 마지막으로 일반 Kubernetes RBAC를 사용하여 클러스터에서 CI/CD 작업의 접근을 제한할 수 있습니다.

이 섹션에서는 모든 CI/CD 작업에 ID를 추가하고 클러스터에서 작업을 가장하여 CI/CD 접근을 제한하는 방법을 보여줍니다.

  1. CI/CD 작업 가장을 구성하려면 .gitlab/agents/testing/config.yaml 파일을 편집하고 다음 스니펫을 추가합니다(path/to/project를 교체):

    ci_access:
   projects:
      - id: my-group/optional-subgroup/my-repository
        access_as:
           ci_job: {}

  2. CI/CD 작업에 아직 클러스터 바인딩이 없으므로 GitLab CI/CD에서 Kubernetes 명령을 실행할 수 없습니다. CI/CD 작업이 flux-system 네임스페이스에서 Secret 객체를 생성할 수 있도록 활성화합니다. 다음 내용으로 clusters/testing/gitlab-ci-job-secret-write.yaml 파일을 생성합니다:

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
   name: secret-manager
   namespace: default
rules:
   - apiGroups: [""]
     resources: ["secrets"]
     verbs: ["create", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
   name: gitlab-ci-secrets-binding
   namespace: default
subjects:
   - kind: Group
     name: gitlab:ci_job
     apiGroup: rbac.authorization.k8s.io
roleRef:
   kind: Role
   name: secret-manager
   apiGroup: rbac.authorization.k8s.io

  3. CI/CD 작업이 FluxCD 조정도 트리거할 수 있도록 활성화합니다. 다음 내용으로 clusters/testing/gitlab-ci-job-flux-reconciler.yaml 파일을 생성합니다:

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
    name: ci-job-admin
roleRef:
    name: flux-edit-flux-system
    kind: ClusterRole
    apiGroup: rbac.authorization.k8s.io
subjects:
    - name: gitlab:ci_job
      kind: Group
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
    name: ci-job-view
roleRef:
    name: flux-view-flux-system
    kind: ClusterRole
    apiGroup: rbac.authorization.k8s.io
subjects:
    - name: gitlab:ci_job
      kind: Group

CI/CD 접근에 대한 자세한 내용은 Kubernetes 클러스터와 GitLab CI/CD 사용을 참조하세요.

리소스 정리#

완료하려면 배포된 리소스를 제거하고 컨테이너 레지스트리에 접근하는 데 사용한 시크릿을 삭제합니다:

  1. clusters/testing/nginx.yaml 파일을 삭제합니다. Flux가 클러스터에서 관련 리소스를 제거합니다.
  2. container-registry-secret 환경을 중지합니다. 환경 중지는 on_stop 작업을 트리거하여 클러스터에서 시크릿을 제거합니다.

다음 단계#

이 튜토리얼의 기법을 사용하여 프로젝트 간에 배포를 확장할 수 있습니다. OCI 이미지는 다른 프로젝트에서 빌드할 수 있으며 Flux가 올바른 레지스트리를 가리키는 한 Flux가 검색합니다. 이 연습은 독자를 위해 남겨둡니다.

더 많은 연습을 위해 /clusters/testing/flux-system/gotk-sync.yaml의 원래 Flux GitRepository를 OCIRepository로 변경해보세요.

마지막으로 Flux와 Kubernetes와의 GitLab 통합에 대한 자세한 내용은 다음 리소스를 참조하세요: