본문으로 바로가기 본문 바로가기
WIKI 기술 지식 베이스

Calico 퀵스타트 가이드

원문 보기 위키 갱신

이 퀵스타트 가이드는 Calico를 설치하고, 네트워크 정책으로 클러스터를 보호하고, Calico Whisker로 네트워크 트래픽을 모니터링하는 방법을 보여줘요. kind로 개인 워크스테이션에 단일 호스트 Kubernetes 클러스터를 만들고 약 15분 안에 따라 할 수 있어요. NGINX·BusyBox 트래픽 실습과 기본 거부(default deny) 정책 적용까지 이어져요.

출처: 문서

본문

시작하기 전에

이 튜토리얼을 완료하려면 몇 가지 도구를 설치해야 해요:

  • kind. 워크스테이션에 클러스터를 만들 때 사용해요. 설치 지침은 kind 문서를 참고하세요.
  • Docker Engine 또는 Docker Desktop. kind 유틸리티가 컨테이너를 실행하는 데 필요해요. 설치 지침은 Docker 문서를 참고하세요.
  • kubectl. 클러스터와 상호작용할 때 사용하는 도구예요. 설치 지침은 Kubernetes 문서를 참고하세요.

단계 1: 클러스터 만들기

이 단계에서 할 일은:

  • 클러스터 만들기: kind로 Kubernetes 클러스터를 만들어요.
  • 클러스터 확인: 클러스터가 실행 중이고 준비됐는지 점검해요.

  1. config.yaml이라는 파일을 만들고 다음 내용을 넣어요:

    kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
  - role: worker
networking:
  disableDefaultCNI: true
  podSubnet: 192.168.0.0/16

    이 구성 파일은 kind에게 컨트롤 플레인 노드 하나와 워커 노드 두 개로 이루어진 클러스터를 만들라고 알려줘요. CNI 없이 클러스터를 만들라고 지시하는 부분도 있어요. podSubnet 범위는 Kubernetes가 파드에 사용할 IP 주소를 정의해요.

  2. 다음 명령을 실행해 구성 파일로 Kubernetes 클러스터를 시작해요:

    kind create cluster --name=calico-cluster --config=config.yaml

    kind가 구성 파일을 읽고 몇 분 안에 클러스터를 만들어요.

    예상 출력

    Creating cluster "calico-cluster" ...
✓ Ensuring node image (kindest/node:v1.29.2) 🖼
✓ Preparing nodes 📦 📦 📦
✓ Writing configuration 📜
✓ Starting control-plane 🕹️
✓ Installing StorageClass 💾
✓ Joining worker nodes 🚜
Set kubectl context to "kind-calico-cluster"
You can now use your cluster with:

kubectl cluster-info --context kind-calico-cluster

Thanks for using kind! 😊

  3. 클러스터가 동작하는지 확인하려면 다음 명령을 실행해요:

    kubectl get nodes

    클러스터에 지정한 이름이 붙은 세 개의 노드가 보일 거예요.

    예상 출력

    NAME                           STATUS     ROLES           AGE     VERSION
calico-cluster-control-plane   NotReady   control-plane   5m46s   v1.29.2
calico-cluster-worker          NotReady   <none>          5m23s   v1.29.2
calico-cluster-worker2         NotReady   <none>          5m22s   v1.29.2

    노드가 Ready 상태가 되길 기다리지 마세요. 다음 단계에서 네트워킹을 구성하기 전까지는 NotReady 상태로 남아 있어요.

단계 2. Calico 설치하기

이 단계에서는 클러스터에 Calico를 설치해요.

  1. Calico 커스텀 리소스 정의를 설치해요.

    클러스터가 Kubernetes 1.36 이상 기반이라면:

    kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.33.0/manifests/v3_projectcalico_org.yaml

    클러스터가 Kubernetes 1.34 또는 1.35 기반이라면:

    kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.33.0/manifests/v3_projectcalico_org-v1beta1.yaml

  2. Tigera Operator를 설치해요.

    kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.33.0/manifests/tigera-operator.yaml

    예상 출력

    namespace/tigera-operator created
serviceaccount/tigera-operator created
clusterrole.rbac.authorization.k8s.io/tigera-operator-secrets created
clusterrole.rbac.authorization.k8s.io/tigera-operator created
clusterrolebinding.rbac.authorization.k8s.io/tigera-operator created
rolebinding.rbac.authorization.k8s.io/tigera-operator-secrets created
deployment.apps/tigera-operator created

  3. 필요한 커스텀 리소스를 만들어 Calico를 설치해요.

    kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.33.0/manifests/custom-resources.yaml

    예상 출력

    installation.operator.tigera.io/default created
apiserver.operator.tigera.io/default created
goldmane.operator.tigera.io/default created
whisker.operator.tigera.io/default created

  4. 다음 명령으로 배포를 모니터링해요:

    watch kubectl get tigerastatus

    몇 분 후에는 모든 Calico 컴포넌트가 AVAILABLE 열에 True로 표시돼요.

    예상 출력

    NAME                            AVAILABLE   PROGRESSING   DEGRADED   SINCE
apiserver                       True        False         False      4m9s
calico                          True        False         False      3m29s
goldmane                        True        False         False      3m39s
ippools                         True        False         False      6m4s
whisker                         True        False         False      3m19s

단계 3. Calico Whisker에서 네트워크 트래픽 모니터링하기

Whisker 웹 콘솔은 자동으로 배포되지만 기본적으로 클러스터 밖에서 접근할 수 없어요. 웹 콘솔을 보려면 접근을 허용해야 해요.

이 단계에서 할 일은:

  • 포트 포워딩 설정: 브라우저에서 Whisker 웹 콘솔에 접근할 수 있게 해줘요.
  • Whisker 웹 콘솔 열기: 네트워크 트래픽 로그를 실시간으로 봐요.

  1. 터미널에서 다음 명령을 실행해요:

    kubectl port-forward -n calico-system service/whisker 8443:8443

    예상 출력

    Forwarding from 127.0.0.1:8443 -> 8443
Forwarding from [::1]:8443 -> 8443

    튜토리얼이 끝날 때까지 이 터미널을 열어 두세요. Whisker 웹 콘솔이 로그를 받으려면 포트 포워딩이 활성 상태여야 해요.

  2. Calico Whisker를 열려면 브라우저를 열고 https://localhost:8443으로 가세요. Calico Whisker는 자체 서명 인증서를 사용하기 때문에 처음에는 브라우저가 보안 경고를 표시해요. 경고를 수락하고 계속하세요. 처음에는 어떤 흐름도 보이지 않아요. 하지만 잠시 후 콘솔이 흐름 로그를 받으면 연결 목록이 보이기 시작해요.

    Whisker

    Figure 1: Whisker 웹 콘솔에 표시된 핵심 Kubernetes 서비스의 허용된 흐름.

    웹 콘솔은 흐름 로그를 실시간으로 쌓아요. 튜토리얼이 끝날 때까지 이 창을 열어 두면 파드가 만드는 연결 로그를 볼 수 있어요.

단계 4. NGINX와 BusyBox로 트래픽 만들기

이제 네트워크 트래픽을 만들 차례예요. 먼저 NGINX 서버를 배포하고 클러스터 안에서 서비스로 노출할 거예요. 그다음 클러스터의 다른 파드에서 NGINX 서버와 외부 웹사이트로 HTTP 요청을 보낼 거예요. 이를 위해 BusyBox 유틸리티를 사용해요.

이 단계에서 할 일은:

  • 서버 만들기: Kubernetes 클러스터에 NGINX 웹 서버를 배포해요.
  • 서버 노출: NGINX 서버를 클러스터 안에서 접근 가능하게 만들어요.
  • 연결 테스트: BusyBox 파드로 NGINX 서버와 공용 인터넷에 대한 연결을 확인해요.

  1. 애플리케이션용 네임스페이스를 만들어요:

    kubectl create namespace quickstart

    예상 출력

    namespace/quickstart created

  2. quickstart 네임스페이스에 NGINX 웹 서버를 배포해요:

    kubectl create deployment --namespace=quickstart nginx --image=nginx

    예상 출력

    deployment.apps/nginx created

  3. NGINX 배포를 노출해서 클러스터 안에서 접근 가능하게 만들어요:

    kubectl expose --namespace=quickstart deployment nginx --port=80

    예상 출력

    service/nginx exposed

  4. NGINX 서버에 접근할 수 있는지 테스트하기 위해 BusyBox 세션을 시작해요.

    kubectl run --namespace=quickstart access --rm -ti --image busybox /bin/sh

    이 명령은 quickstart 네임스페이스 안에 BusyBox 파드를 만들고 파드 안에서 셸 세션을 시작해요.

    예상 출력

    If you don't see a command prompt, try pressing enter.
/ #

  5. BusyBox 셸에서 다음 명령을 실행해 NGINX 서버와의 통신을 테스트해요:

    wget -qO- http://nginx

    NGINX 환영 페이지의 HTML 내용이 보일 거예요.

    예상 출력

    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

    BusyBox 파드가 NGINX 서버에 접근할 수 있다는 뜻이에요.

  6. BusyBox 셸에서 다음 명령을 실행해 공용 인터넷과의 통신을 테스트해요:

    wget -qO- https://docs.tigera.io/pod-connection-test.txt

    pod-connectivity-test.txt 파일의 내용이 보일 거예요.

    예상 출력

    You successfully connected to https://docs.tigera.io/pod-connection-test.txt.

    BusyBox 파드가 공용 인터넷에 접근할 수 있다는 뜻이에요.

  7. 브라우저로 돌아가서 Whisker 웹 콘솔에 연결이 나타나는지 보세요. 새로운 연결 유형 세 개가 보일 거예요: coredns로 가는 것, nginx로 가는 것, 그리고 PUBLIC NETWORK로 가는 것이에요.

    whisker2

    Figure 2: NGINX 서버와 https://docs.tigera.io로의 허용된 흐름을 보여주는 Whisker 웹 콘솔.

단계 5. 기본 거부 정책으로 모든 트래픽 제한하기

클러스터를 효과적으로 보호하려면 모든 트래픽을 거부하는 것에서 시작하고, 필요한 트래픽만 점진적으로 허용하는 게 가장 좋아요. 여기서는 모든 인그레스와 이그레스 트래픽을 기본적으로 거부하는 글로벌 Calico 네트워크 정책을 적용해 볼 거예요.

이 단계에서 할 일은:

  • 글로벌 기본 거부 정책 구현: 글로벌 Calico 네트워크 정책으로 모든 인그레스와 이그레스 트래픽을 기본적으로 거부해요.
  • 접근이 거부되는지 확인: BusyBox 파드로 정책이 기대대로 동작하는지 확인해요.

  1. 필요한 시스템 네임스페이스를 제외한 모든 트래픽을 거부하는 글로벌 Calico 네트워크 정책을 만들어요:

    kubectl create -f - <<EOF
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: default-deny
spec:
  selector: projectcalico.org/namespace not in {'kube-system', 'calico-system', 'calico-apiserver'}
  types:
    - Ingress
    - Egress
EOF

    예상 출력

    globalnetworkpolicy.projectcalico.org/default-deny created

  2. 이제 BusyBox 셸로 돌아가서 NGINX 서버 접근을 다시 테스트해요:

    wget -qO- http://nginx

    접근이 거부됐다는 뜻의 다음 출력이 보일 거예요:

    예상 출력

    wget: bad address 'nginx'

  3. 공용 인터넷 접근도 다시 테스트해요:

    wget -qO- https://docs.tigera.io/pod-connection-test.txt

    이그레스 트래픽도 거부됐다는 뜻의 다음 출력이 보일 거예요:

    예상 출력

    wget: bad address 'docs.tigera.io'

  4. 브라우저로 돌아가서 Whisker 웹 콘솔에 거부된 흐름 로그가 나타나는지 보세요. coredns로 가는 거부된 흐름 두 개가 보일 거예요.

    whisker3

    Figure 3: NGINX 서버와 https://docs.tigera.io로의 거부된 흐름을 보여주는 Whisker 웹 콘솔.

    이 단계들을 따라 하면 글로벌 기본 거부 정책을 성공적으로 구현하고 기대대로 동작하는지 확인한 거예요.

단계 6. 허용할 트래픽을 위한 타깃 네트워크 정책 만들기

이제 기본 거부 정책이 자리 잡았으니, 애플리케이션이 동작하는 데 필요한 트래픽만 허용하는 개별 정책을 만들어야 해요. default-deny 정책은 시스템 네임스페이스에 있지 않은 파드의 모든 인그레스와 이그레스 트래픽을 막아요. quickstart 네임스페이스의 access(BusyBox)와 nginx 파드도 포함해서요.

이 단계에서 할 일은:

  • BusyBox의 이그레스 트래픽 허용 BusyBox 파드에서 공용 인터넷으로 가는 이그레스 트래픽을 허용하는 네트워크 정책을 만들어요.
  • NGINX로의 인그레스 트래픽 허용 NGINX 서버로 들어오는 인그레스 트래픽을 허용하는 네트워크 정책을 만들어요.

  1. quickstart 네임스페이스에 access 파드를 선택하고 그 파드의 모든 이그레스 트래픽을 허용하는 Calico 네트워크 정책을 만들어요.

    kubectl create -f - <<EOF
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-busybox-egress
  namespace: quickstart
spec:
  selector: run == 'access'
  types:
  - Egress
  egress:
  - action: Allow
EOF

    예상 출력

    networkpolicy.projectcalico.org/allow-busybox-egress created

  2. BusyBox 셸로 돌아가서 공용 인터넷 접근을 다시 테스트해요. 이 파드의 이그레스 트래픽이 이제 허용되기 때문에 성공해야 해요:

    wget -qO- https://docs.tigera.io/pod-connection-test.txt

    예상 출력

    You successfully connected to https://docs.tigera.io/pod-connection-test.txt.

  3. NGINX 서버 접근을 다시 테스트해요. access 파드 에서의 이그레스는 새 정책이 허용하지만, nginx 파드 로의 인그레스는 여전히 default-deny 정책이 막고 있어요. 이 요청은 실패해야 해요.

    wget -qO- http://nginx

    예상 출력

    wget: bad address 'nginx'

  1. quickstart 네임스페이스에 또 다른 Calico 네트워크 정책을 만들어요. 이 정책은 nginx 파드를 선택하고(레이블 app=nginx 사용) 레이블이 run=access인 파드 에서 오는 인그레스 트래픽을 구체적으로 허용해요.

    kubectl create -f - <<EOF
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-nginx-ingress
  namespace: quickstart
spec:
  selector: app == 'nginx'
  types:
  - Ingress
  ingress:
  - action: Allow
    source:
      selector: run == 'access'
EOF

    예상 출력

    networkpolicy.org/allow-nginx-ingress created

  2. NGINX 서버 접근을 다시 테스트해요. BusyBox 셸에서 NGINX 서버 접근을 한 번 더 테스트해요:

    wget -qO- http://nginx

    이제 access 에서 오는 이그레스와 nginx 로 들어오는(access에서 오는) 인그레스가 모두 허용되기 때문에 연결이 성공해야 해요. NGINX 환영 페이지가 보일 거예요:

    예상 출력

    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

이제 기본 거부 정책을 성공적으로 구현한 뒤, 타깃 허용 정책을 만들어 애플리케이션에만 연결성을 되돌려 준 거예요.

단계 7. 정리하기

  • kind 클러스터를 제거하려면 다음 명령을 실행해요:

    kind delete cluster --name calico-cluster

    예상 출력

    Deleting cluster "calico-cluster" ...
Deleted nodes: ["calico-cluster-control-plane" "calico-cluster-worker2" "calico-cluster-worker"]

추가 리소스

  • 더 깊이 들어가고 싶나요? 브라우저에서 바로 진행하는 무료 인터랙티브 워크숩으로 Calico 기초, Whisker를 활용한 Kubernetes 옵저버빌리티 등을 배워 보세요.

더 알아보기 (Learn more)

이 퀵스타트의 핵심 흐름은 "모두 거부 → 필요한 것만 허용"이에요. 기본 거부 정책을 먼저 걸고 인그레스·이그레스를 하나씩 열어 주는 습관이 실전 클러스터 보안의 기본이 돼요. Whisker 콘솔의 흐름 로그를 함께 보면 정책이 실제로 트래픽에 어떻게 적용되는지 즉시 확인할 수 있어요.