kpt를 사용하여 클라우드 인프라 관리

Last reviewed 2023-03-15 UTC
이 튜토리얼에서는 패키징, 가져오기, 업데이트, 수정과 같은 Kubernetes 구성(매니페스트라고도 함) 작업을 수행할 수 있게 해주는 Google 제공 오픈소스 도구인 kpt를 소개합니다. kpt는 이러한 구성과 해당 구성에서의 작업을 명확하게 구분하고 싶을 때 사용되는 템플릿 기반 도구를 대신합니다. kpt를 사용하면 구성 수정 또는 조사와 같이 해당 구성에서 작동하는 코드를 재사용하고 공유할 수 있습니다.

또한 이 튜토리얼에서는 kpt를 구성 동기화 및 GKE Enterprise 보안 청사진과 같은 다른 Google 솔루션과 결합하는 방법을 보여줍니다. Kubernetes를 사용하는 개발자든 Kubernetes 기반 플랫폼을 관리하는 플랫폼 엔지니어든 이 튜토리얼을 통해 자체 Kubernetes 관련 워크플로에서 kpt를 사용하는 방법을 알아볼 수 있습니다. 이 튜토리얼에서는 사용자가 Kubernetes 및 Google Cloud에 익숙하다고 가정합니다.

클라우드 인프라의 선언적 구성은 IT 업계에서 널리 사용되고 있으며, 기본 시스템의 강력한 추상화를 제공합니다. 이 추상화로 인해 하위 수준 구성 세부정보와 종속 항목을 관리할 필요가 없습니다. 따라서 선언적 구성은 그래픽 및 명령줄 인터페이스에서 수행되는 작업과 같은 명령형 접근 방식에 비해 이점이 있습니다.

Kubernetes 리소스 모델은 선언적 구성 접근 방식을 주류로 만드는 데 큰 영향을 미쳤습니다. Kubernetes API는 기본적으로 완전히 선언적이므로 Kubernetes에 원하는 결과를 얻기 위한 방법이 아닌 원하는 결과만 알려주면 됩니다. Kubernetes API를 사용하면 원하든 실제이든 구성을 구성의 작업(객체 추가, 삭제, 수정)과 명확하게 구분할 수 있습니다. 즉, Kubernetes 리소스 모델에서 구성은 데이터이며 코드가 아닙니다.

이렇게 구성을 구분하면 많은 이점이 있습니다. 사람과 자동 시스템이 구성을 이해하고 작업할 수 있으며 구성을 수정하는 소프트웨어를 쉽게 재사용할 수 있습니다. 이렇게 구분하면 Cloud Build로 GitOps 스타일의 지속적 배포 튜토리얼에 정의된 것처럼 GitOps 방법을 쉽게 구현할 수 있습니다.

이 튜토리얼에서는 kpt를 사용하여 구성 작업에서 이 구성 선언의 구분을 살펴봅니다. 이 튜토리얼에서는 kpt의 다음과 같은 기능을 중점적으로 설명합니다.

  • 패키지 관리: Kubernetes 구성 패키지를 다운로드하고 업데이트합니다.
  • 함수: 임의의 코드 조각을 실행하여 구성을 수정하거나 검증합니다.
  • 함수 파이프라인: 패키지와 함께 패키지 작성자가 포함한 함수 집합입니다.
  • 리소스 관리: Kubernetes 클러스터의 구성에 해당하는 리소스를 적용, 업데이트, 삭제합니다.

목표

  • Google Kubernetes Engine(GKE) 클러스터를 만듭니다.
  • kpt를 사용하여 기존 Kubernetes 구성 집합을 다운로드합니다.
  • kpt 함수를 사용하여 구성을 맞춤설정합니다.
  • GKE 클러스터에 구성을 적용합니다.
  • kpt를 사용하여 구성의 몇 가지 업스트림 변경사항을 가져옵니다.
  • 실제 시나리오에서 kpt를 사용하여 GKE 클러스터를 강화하세요.

비용

이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.

  • Google Kubernetes Engine

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요. Google Cloud를 처음 사용하는 사용자는 무료 체험판을 사용할 수 있습니다.

시작하기 전에

  1. Google Cloud 계정에 로그인합니다. Google Cloud를 처음 사용하는 경우 계정을 만들고 Google 제품의 실제 성능을 평가해 보세요. 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.

  2. Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.

    프로젝트 선택기로 이동

  3. Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

  4. Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.

    프로젝트 선택기로 이동

  5. Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

  6. Google Cloud 콘솔에서 Cloud Shell을 활성화합니다.

    Cloud Shell 활성화

    Google Cloud 콘솔 하단에서 Cloud Shell 세션이 시작되고 명령줄 프롬프트가 표시됩니다. Cloud Shell은 Google Cloud CLI가 사전 설치된 셸 환경으로, 현재 프로젝트의 값이 이미 설정되어 있습니다. 세션이 초기화되는 데 몇 초 정도 걸릴 수 있습니다.

  7. 프로젝트를 사용하도록 Cloud Shell을 구성합니다.

    gcloud config set project PROJECT_ID

  8. Cloud Shell에서 Google Kubernetes Engine 및 Cloud Source Repositories API를 사용 설정합니다.

    gcloud services enable container.googleapis.com \
   sourcerepo.googleapis.com

이 가이드를 마친 후에 계속 비용이 청구되지 않도록 하려면 만든 리소스를 삭제하면 됩니다. 자세한 내용은 삭제를 참조하세요.

GKE 클러스터 만들기

이 섹션에서는 가이드 뒷부분에서 구성을 배포할 GKE 클러스터를 만듭니다.

  1. Cloud Shell에서 GKE 클러스터를 만듭니다.

    gcloud container clusters create kpt-tutorial \
   --num-nodes=1 --machine-type=n1-standard-4 \
   --zone=us-central1-a --enable-network-policy

  2. 클러스터에 액세스할 수 있는지 확인합니다. 다음 명령어는 클러스터에 있는 노드 또는 노드에 대한 정보를 반환합니다.

    kubectl get nodes

kpt 패키지 적용

이 섹션에서는 kpt를 사용하여 구성 집합을 다운로드하고 맞춤설정한 후 이전 섹션에서 만든 클러스터에 적용합니다. kpt는 Cloud Shell 환경 내에 설치되어 있어야 합니다. 그렇지 않은 경우 다음 명령어를 사용하여 설치합니다.

  1. Cloud Shell에서 kpt를 설치합니다.

    sudo apt update && sudo apt-get install google-cloud-sdk-kpt

  2. 구성 집합 예시를 다운로드합니다. 자세한 내용은 kpt pkg get를 참조하세요.

    kpt pkg get https://github.com/GoogleContainerTools/kpt.git/package-examples/wordpress@v0.9

    위의 명령어는 kpt GitHub 저장소의 v0.9으로 태그가 지정된 파일에서 사용 가능한 wordpress 샘플 패키지를 다운로드합니다.

  3. 패키지 콘텐츠를 검사합니다(kpt pkg tree).

    kpt pkg tree wordpress

    출력은 다음과 같이 표시됩니다.

    Package "wordpress"
├── [Kptfile]  Kptfile wordpress
├── [service.yaml]  Service wordpress
├── deployment
│   ├── [deployment.yaml]  Deployment wordpress
│   └── [volume.yaml]  PersistentVolumeClaim wp-pv-claim
└── Package "mysql"
    ├── [Kptfile]  Kptfile mysql
    ├── [deployment.yaml]  PersistentVolumeClaim mysql-pv-claim
    ├── [deployment.yaml]  Deployment wordpress-mysql
    └── [deployment.yaml]  Service wordpress-mysql

    이 패키지에는 최상위 항목인 wordpress와 하위 패키지인 wordpress/mysql의 두 패키지가 포함되며, 두 패키지 모두 메타데이터 파일 Kptfile을 포함합니다. Kptfile은 kpt 자체에서만 사용되며, 패키지의 업스트림 소스, 맞춤설정, 검증에 대한 데이터를 포함합니다.

  4. 패키지 라벨 업데이트

    패키지 작성자는 필요한 맞춤설정을 전달하기 위해 자주 사용되는 렌더링 파이프라인을 추가했습니다.

    less wordpress/Kptfile

    이 콘텐츠는 다음과 같이 표시됩니다.

    apiVersion: kpt.dev/v1
kind: Kptfile
metadata:
  name: wordpress
upstream:
  type: git
  git:
    repo: https://github.com/GoogleContainerTools/kpt
    directory: /package-examples/wordpress
    ref: v0.9
  updateStrategy: resource-merge
upstreamLock:
  type: git
  git:
    repo: https://github.com/GoogleContainerTools/kpt
    directory: /package-examples/wordpress
    ref: package-examples/wordpress/v0.9
    commit: b9ea0bca019dafa9f9f91fd428385597c708518c
info:
  emails:
    - kpt-team@google.com
  description: This is an example wordpress package with mysql subpackage.
pipeline:
  mutators:
    - image: gcr.io/kpt-fn/set-labels:v0.1
      configMap:
        app: wordpress
  validators:
    - image: gcr.io/kpt-fn/kubeval:v0.3

    자주 사용하는 편집기를 사용하여 set-label 함수를 app: wordpress에서 app: my-wordpress로 변경할 수 있습니다.

  5. 원하는 코드 편집기를 사용하여 MySQL 배포 wordpress/mysql/deployment.yaml을 수정하여 MySQL 버전을 변경합니다. 또한 보안을 더 강화하기 위해 MYSQL_ROOT_PASSWORD 변수를 MYSQL_PASSWORD로 변경하고 다음 변수를 추가합니다.

    • MYSQL_USER
    • MYSQL_RANDOM_ROOT_PASSWORD
    • MYSQL_DATABASE

    실행 전:

    [...]
  containers:
    - name: mysql
      image: mysql:5.6
      ports:
        - name: mysql
          protocol: TCP
          containerPort: 3306
      env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
[...]

    실행 후:

    [...]
  containers:
    - name: mysql
      image: mysql:8.0
      ports:
        - name: mysql
          protocol: TCP
          containerPort: 3306
      env:
        - name: MYSQL_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        - name: MYSQL_RANDOM_ROOT_PASSWORD
          value: '1'
        - name: MYSQL_USER
          value: wordpress
        - name: MYSQL_DATABASE
          value: wordpress
[...]

  6. 즐겨찾는 코드 편집기를 사용하여 Wordpress 배포(wordpress/deployment/deployment.yaml)를 수정하여 Wordpress 버전을 변경하고 WORDPRESS_DB_USER 변수를 추가합니다.

    실행 전:

    [...]
  containers:
    - name: wordpress
      image: wordpress:6.1-apache
      ports:
        - name: wordpress
          protocol: TCP
          containerPort: 80
      env:
        - name: WORDPRESS_DB_HOST
          value: wordpress-mysql
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
[...]

    실행 후:

    [...]
  containers:
    - name: wordpress
      image: wordpress:4.8-apache
      ports:
        - name: wordpress
          protocol: TCP
          containerPort: 80
      env:
        - name: WORDPRESS_DB_HOST
          value: wordpress-mysql
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        - name: WORDPRESS_DB_USER
          value: wordpress
[...]

    매개변수를 통해서만 작동하는 도구와 달리 kpt를 사용하면 편집기를 사용하여 그 자리에서 파일을 수정한 후 이를 업스트림 업데이트에 병합할 수 있습니다. 패치를 만들거나 파이프라인에 함수를 만들 필요 없이 직접 deployment.yaml을 수정할 수 있습니다.

  7. sample-annotation: sample-value로 구성에 주석을 지정합니다.

    kpt fn eval wordpress --image gcr.io/kpt-fn/set-annotations:v0.1 \
  -- sample-annotation=sample-value

    출력은 다음과 같이 표시됩니다.

    [RUNNING] "gcr.io/kpt-fn/set-annotations:v0.1"
[PASS] "gcr.io/kpt-fn/set-annotations:v0.1"

    새 주석을 보려면 구성 값을 조사하면 됩니다. 간단하게 볼 수 있는 것은 wordpress/service.yaml입니다.

    이 예시에서는 패키지 작성자가 계획하지 않은 방법으로 함수를 사용하는 맞춤설정을 수행했습니다. kpt는 더 다양한 범위의 시나리오를 위해 선언적 및 명령적 함수 실행을 지원할 수 있습니다.

    이 패키지가 infrastructure-as-code를 사용하여 개발된 경우에는 해당 패키지 소스로 이동하고 그곳에서 코드를 수정해야 합니다.

  8. kpt를 통해 kubeval을 사용하여 파이프라인을 실행하고 변경사항을 검사합니다.

    kpt fn render wordpress

    패키지 작성자가 파이프라인에 검사 단계를 포함시켰습니다.

    ...
validators:
    - image: gcr.io/kpt-fn/kubeval:v0.3

    이 렌더링 파이프라인이 성공한 출력은 다음과 같이 표시됩니다.

    Package "wordpress/mysql":
[RUNNING] "gcr.io/kpt-fn/set-labels:v0.1"
[PASS] "gcr.io/kpt-fn/set-labels:v0.1" in 1.3s

Package "wordpress":
[RUNNING] "gcr.io/kpt-fn/set-labels:v0.1"
[PASS] "gcr.io/kpt-fn/set-labels:v0.1" in 1.3s
[RUNNING] "gcr.io/kpt-fn/kubeval:v0.3"
[PASS] "gcr.io/kpt-fn/kubeval:v0.3" in 3.7s

Successfully executed 3 function(s) in 2 package(s).

    이 단계는 Kubernetes 리소스 모델의 이점 예시입니다. 구성이 이 알려진 모델에 표시되므로 kubeval과 같은 기존 Kubernetes 도구를 사용할 수 있습니다.

  9. 구성의 로컬 버전과 업스트림 구성의 차이점을 검토합니다.

    kpt pkg diff wordpress

  10. 배포용 패키지를 초기화합니다.

    kpt live init wordpress

    위의 명령어는 패키지에 있는 구성의 인벤토리를 빌드합니다. 무엇보다도 kpt는 패키지에서 구성을 삭제할 때 인벤토리를 사용하여 구성을 프루닝합니다. 자세한 내용은 kpt live를 참조하세요.

  11. MySQL 비밀번호가 포함된 보안 비밀을 만듭니다.

    kubectl create secret generic mysql-pass --from-literal=password=foobar

  12. GKE 클러스터에 구성을 적용합니다.

    kpt live apply wordpress

    출력은 다음과 같이 표시됩니다.

    installing inventory ResourceGroup CRD.
inventory update started
inventory update finished
apply phase started
service/wordpress apply successful
service/wordpress-mysql apply successful
deployment.apps/wordpress apply successful
deployment.apps/wordpress-mysql apply successful
persistentvolumeclaim/mysql-pv-claim apply successful
persistentvolumeclaim/wp-pv-claim apply successful
apply phase finished
reconcile phase started
service/wordpress reconcile successful
service/wordpress-mysql reconcile successful
deployment.apps/wordpress reconcile pending
deployment.apps/wordpress-mysql reconcile pending
persistentvolumeclaim/mysql-pv-claim reconcile pending
persistentvolumeclaim/wp-pv-claim reconcile pending
persistentvolumeclaim/wp-pv-claim reconcile successful
persistentvolumeclaim/mysql-pv-claim reconcile successful
deployment.apps/wordpress-mysql reconcile successful
deployment.apps/wordpress reconcile successful
reconcile phase finished
inventory update started
inventory update finished
apply result: 6 attempted, 6 successful, 0 skipped, 0 failed
reconcile result: 6 attempted, 6 successful, 0 skipped, 0 failed, 0 timed out

  13. 몇 분 정도 기다린 후 모든 것이 예상대로 실행되고 있는지 확인합니다.

    kpt live status wordpress

    출력은 다음과 같이 표시됩니다.

    inventory-88521939/deployment.apps/default/wordpress is Current: Deployment is available. Replicas: 1
inventory-88521939/persistentvolumeclaim/default/wp-pv-claim is Current: PVC is Bound
inventory-88521939/service/default/wordpress-mysql is Current: Service is ready
inventory-88521939/persistentvolumeclaim/default/mysql-pv-claim is Current: PVC is Bound
inventory-88521939/deployment.apps/default/wordpress-mysql is Current: Deployment is available. Replicas: 1
inventory-88521939/service/default/wordpress is Current: Service is ready

로컬 패키지 업데이트

이 섹션에서는 업스트림 패키지의 일부 변경사항으로 패키지의 로컬 버전을 업데이트합니다.

  1. 구성의 Git 저장소를 만들고 이메일 및 이름을 구성합니다. 패키지를 업데이트하려면 로컬 Git 저장소가 필요합니다. YOUR_EMAIL를 이메일 주소로, YOUR_NAME을 이름으로 바꿉니다.

    cd wordpress/
git init -b main
git config user.email "YOUR_EMAIL"
git config user.name "YOUR_NAME"

  2. 구성을 커밋합니다.

    git add .
git commit -m "First version of Wordpress package"
cd ..

  3. 로컬 패키지를 업데이트합니다. 이 단계에서는 업스트림에서 v0.10 버전을 가져옵니다.

    kpt pkg update wordpress@v0.10

  4. 업스트림의 업데이트가 로컬 패키지에 적용되었는지 확인합니다.

    cd wordpress/
git diff

    이 경우 업데이트로 wordpress 배포 볼륨이 3Gi에서 4Gi로 변경되었습니다. 또한 자체 변경사항을 확인할 수도 있습니다.

  5. 변경사항을 커밋합니다.

    git commit -am "Update to package version v0.10"

  6. 패키지의 새 버전을 적용합니다.

    kpt live apply .

리소스 및 패키지 삭제

kpt는 생성하는 리소스를 추적하므로 패키지에서 리소스를 삭제할 때 클러스터에서 리소스를 프루닝할 수 있습니다. 클러스터에서 패키지를 완전히 삭제할 수도 있습니다. 이 섹션에서는 패키지에서 리소스를 삭제한 다음 패키지를 삭제합니다.

  1. 패키지에서 service.yaml 파일을 삭제합니다.

    git rm service.yaml
git commit -m "Remove service"

  2. 변경사항을 적용하고 kpt가 wordpress 서비스를 프루닝했는지 확인합니다.

    kpt live apply .
kubectl get svc

  3. 클러스터에서 나머지 패키지를 삭제한 뒤 클러스터에 남아 있는 항목이 없는지 확인합니다.

    kpt live destroy .
kubectl get deployment

kpt를 사용하여 GKE 강화

kpt live 명령어가 Kubernetes 클러스터에 패키지를 적용할 수 있는 유일한 방법은 아닙니다. 이 섹션에서는 기본적이지만 현실적인 시나리오에서 kpt를 구성 동기화와 함께 사용합니다. 구성 동기화 도구를 사용하면 Git 저장소의 모든 Kubernetes 클러스터에 대한 구성을 중앙에서 균일하게 선언적으로 관리할 수 있습니다. 이 튜토리얼에서 사용하는 GKE Enterprise에는 구성 동기화가 포함됩니다.

GKE Enterprise 보안 청사진은 GKE Enterprise 기반 워크로드를 위한 다양한 사전 패키지된 보안 설정을 제공합니다. 이 섹션에서는 트래픽 제한 청사진(및 GitHub 저장소의 해당 디렉터리)을 사용합니다. kpt를 사용하여 default-deny 패키지를 다운로드합니다. 이 패키지는 Kubernetes 네트워크 정책을 사용하여 기본적으로 GKE 클러스터의 트래픽을 거부합니다(DNS 변환 제외). 구성을 적용하려면 구성을 구성 동기화 Git 저장소에 커밋합니다.

Config Sync 설치하기

이 섹션에서는 구성 동기화에 필요한 Git 저장소를 만든 다음 구성 동기화를 GKE 클러스터에 설치합니다.

  1. Cloud Shell에서 Cloud Source Repositories를 사용하여 구성 동기화용 Git 저장소를 만듭니다.

    cd ~
gcloud source repos create config-management

  2. Git 저장소에 대해 인증하기 위한 SSH 키 쌍을 생성합니다.

    cd ~
ssh-keygen -t rsa -b 4096  -N '' \
   -f cloud_source_repositories_key

  3. SSH 비공개 키가 포함된 Kubernetes 보안 비밀을 만들어 Git 저장소에 액세스합니다.

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
  --namespace=config-management-system \
  --from-file=ssh=cloud_source_repositories_key

  4. 공개 키를 표시한 다음 복사합니다.

    cat cloud_source_repositories_key.pub

  5. Cloud Source Repositories로 이동

    SSH 키 관리 페이지.

  6. SSH 키 등록 대화상자가 나타나면 다음 값을 입력합니다.

    1. 키 이름 필드에 config-management를 입력합니다.
    2. 키 필드에 공개 키를 붙여넣습니다.
    3. 등록을 클릭합니다.

  7. Git 저장소를 Cloud Shell에 클론합니다.

    gcloud source repos clone config-management
cd config-management
git checkout -b main

  8. nomos라는 구성 동기화 명령줄 도구를 다운로드합니다. nomos는 Cloud Shell 환경 내에 설치되어야 합니다. 그렇지 않은 경우 다음 명령어를 사용하여 설치합니다.

    sudo apt update && sudo apt-get install google-cloud-sdk-nomos

  9. 구성 동기화 저장소를 초기화합니다.

    nomos init
git add .
git commit -m "Config Management directory structure"
git push -u origin main

  10. 구성 동기화 연산자를 배포합니다.

    gsutil cp gs://config-management-release/released/latest/config-management-operator.yaml /tmp/config-management-operator.yaml
kubectl apply -f /tmp/config-management-operator.yaml

구성 동기화 구성

  1. ConfigManagement 커스텀 리소스를 만들어 구성 동기화를 구성합니다.

    PROJECT=$(gcloud config get-value project)
EMAIL=$(gcloud config get-value account)
cat <<EOF > /tmp/config-management.yaml
apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  clusterName: kpt-tutorial
  git:
    syncRepo: ssh://${EMAIL}@source.developers.google.com:2022/p/${PROJECT}/r/config-management
    syncBranch: main
    secretType: ssh
EOF
kubectl -n config-management-system \
    apply -f /tmp/config-management.yaml

    추가 설치 옵션은 구성 동기화 문서를 참조하세요.

  2. Cloud Shell에서 구성 동기화가 올바르게 작동하는지 확인합니다.

    nomos status --contexts=$(kubectl config current-context)

    이 명령어는 상태를 SYNCED로 반환합니다. 구성 동기화가 초기화되는 데 다소 시간이 걸릴 수 있습니다. 상태가 업데이트되지 않으면 몇 분 정도 기다린 다음 명령어를 다시 실행합니다.

GKE Enterprise 보안 청사진 적용

이 섹션에서는 kpt를 사용하여 제한된 트래픽 GKE Enterprise 보안 청사진의 default-deny 패키지를 다운로드합니다. 그런 다음 구성 동기화를 사용하여 패키지를 default 네임스페이스에만 적용합니다.

  1. default-deny 패키지를 다운로드합니다.

    cd ~
kpt pkg get https://github.com/GoogleCloudPlatform/anthos-security-blueprints.git/restricting-traffic/default-deny ./

    패키지의 콘텐츠를 탐색할 수 있습니다. default-deny/Kptfile 파일에는 패키지의 메타데이터가 포함되고 default-deny/default-deny.yaml 파일에는 이 청사진의 유일한 구성인 Kubernetes NetworkPolicy가 포함됩니다.

  2. kpt를 사용하여 구성 동기화 저장소에서 패키지의 콘텐츠를 복사한 다음 라벨을 추가하여 맞춤설정합니다.

    kpt fn source default-deny/ | \
    kpt fn eval - --image=gcr.io/kpt-fn/set-annotations:v0.1 -- \
    anthos-security-blueprint=restricting-traffic | \
    kpt fn sink ~/config-management/namespaces/default/

    이 예시에서와 같이 파이프를 사용하여 kpt fn 명령어를 함께 연결할 수 있습니다. kpt fn 명령어를 연결하면 구성을 읽고, 원하는 대로 수정하고, 결과를 작성할 수 있습니다. 원하는 만큼 kpt fn 명령어를 연결할 수 있습니다.

  3. 구성 동기화 저장소에 namespace.yaml 파일을 만듭니다.

    cat >> ~/config-management/namespaces/default/namespace.yaml <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: default
EOF

    default 네임스페이스는 GKE 클러스터에 있지만 구성 동기화에서는 관리하지 않습니다. 이 단계의 디렉터리와 파일을 만들 때 구성 동기화에서 네임스페이스를 관리하도록 합니다. 패키지를 한 번에 여러 네임스페이스에 적용하려면 추상 네임스페이스를 만들면 됩니다.

  4. Kubernetes NetworkPolicy가 구성 동기화 저장소에 작성되었고 anthos-security-blueprint: restricting-traffic으로 주석이 추가되었는지 확인합니다.

    cat config-management/namespaces/default/default-deny.yaml

    출력은 다음과 같이 표시됩니다.

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata: # kpt-merge: /default-deny
  name: default-deny
  annotations:
    internal.kpt.dev/upstream-identifier: 'networking.k8s.io|NetworkPolicy|default|default-deny'
    anthos-security-blueprint: restricting-traffic
spec:
  policyTypes:
  - Ingress
  - Egress
  podSelector: {}
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          k8s-namespace: kube-system
      podSelector:
        matchExpressions:
        - key: k8s-app
          operator: In
          values: ["kube-dns", "node-local-dns"]
    ports:
    - protocol: TCP
      port: 53
    - protocol: UDP
      port: 53

  5. 변경사항을 커밋하고 푸시합니다.

    cd ~/config-management/
git add namespaces/default/
git commit -m "Default deny"
git push

  6. 새 정책이 적용되었는지 확인합니다.

    kubectl get networkpolicies

    새 정책이 없는 경우 몇 초 정도 기다린 후 명령어를 다시 실행합니다. 구성 동기화는 기본적으로 15초마다 구성을 업데이트합니다. 추가 문제 해결이 필요한 경우 다음 명령어를 실행하여 잠재적인 구성 동기화 오류에 대한 정보를 가져옵니다.

    nomos status --contexts=$(kubectl config current-context)

  7. 새 정책을 테스트하려면 default 네임스페이스 내에서 실행 중인 pod에서 셸을 가져옵니다.

    kubectl -n default run -i --tty --rm test \
        --image=busybox --restart=Never -- sh

  8. 8.8.8.8을 핑하여 예상대로 작동하지 않는지 확인합니다.

    ping -c 3 -W 1 8.8.8.8

    출력은 다음과 같이 표시됩니다.

    PING 8.8.8.8 (8.8.8.8): 56 data bytes

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

  9. Kubernetes API 서버를 쿼리하고 예상대로 작동하지 않는지 확인합니다.

    wget --timeout=3 https://${KUBERNETES_SERVICE_HOST}

    출력은 다음과 같이 표시됩니다.

    Connecting to 10.3.240.1 (10.3.240.1:443)
wget: download timed out

  10. pod를 종료합니다.

    exit

삭제

이 튜토리얼에서 사용된 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 리소스가 포함된 프로젝트를 삭제하거나 프로젝트를 유지하고 개별 리소스를 삭제하세요.

프로젝트 삭제

  1. Google Cloud 콘솔에서 리소스 관리 페이지로 이동합니다.

    리소스 관리로 이동

  2. 프로젝트 목록에서 삭제할 프로젝트를 선택하고 삭제를 클릭합니다.
  3. 대화상자에서 프로젝트 ID를 입력한 후 종료를 클릭하여 프로젝트를 삭제합니다.

리소스 삭제

이 가이드에서 사용한 Google Cloud 프로젝트를 유지하려면 Git 저장소와 GKE 클러스터를 삭제하면 됩니다. Cloud Shell에서 다음 명령어를 실행합니다.

gcloud source repos delete config-management --quiet
gcloud container clusters delete kpt-tutorial \
    --async --quiet --zone=us-central1-a

다음 단계