온프레미스 배포를 위한 Calico 네트워킹 및 네트워크 정책 설치

셀프 관리형 온프레미스 Kubernetes 클러스터에 Calico를 설치해 네트워킹과 네트워크 정책을 한 번에 세팅하는 방법을 안내해요. 기본 권장 방식은 Tigera Operator 설치이고, 매니페스트 기반 설치나 v1 CRD에서 v3 CRD로의 마이그레이션 절차도 함께 다뤄요. 코드 블록과 매니페스트 내용은 원문 그대로 유지했으니 명령어를 그대로 따라 치면 돼요.

출처: 문서

본문

큰 그림 (Big picture)

Calico를 설치하면 셀프 관리형 온프레미스 배포에 네트워킹과 네트워크 정책을 모두 제공할 수 있어요.

가치 (Value)

Calico 네트워킹과 네트워크 정책은 CaaS 구현에 강력한 선택지예요. 온프레미스에서 Kubernetes를 운영할 네트워킹 인프라와 리소스를 갖추고 있다면, Calico 전체 제품을 설치하는 것이 가장 많은 커스터마이즈와 제어력을 제공해요.

개념 (Concepts)

권장: Tigera Operator

Calico는 설치, 업그레이드, 전반적인 수명 주기를 관리하는 operator가 설치해 줘요. operator는 클러스터에 Deployment 형태로 직접 설치되고, 하나 이상의 커스텀 Kubernetes API 리소스로 설정돼요.

Calico 매니페스트

operator 대안으로 raw 매니페스트로도 Calico를 설치할 수 있어요. 매니페스트에는 클러스터의 각 노드에 Calico를 설치하는 데 필요한 리소스가 담겨 있어요. 매니페스트 방식은 operator처럼 Calico의 수명 주기를 자동으로 관리할 수 없어서 권장하지 않아요. 다만 Kubernetes 리소스를 아주 특수하게 수정해야 하는 클러스터에는 유용할 수 있어요.

시작하기 전에

• Kubernetes 클러스터가 요구 사항을 충족하는지 확인하세요. 클러스터가 아직 없다면 kubeadm 설치 문서를 참고하세요.

방법 (How to)

• Calico 설치하기

Calico 설치하기 (Install Calico)

탭: Operator

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

   클러스터가 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
   

3. Calico 설정에 필요한 커스텀 리소스를 내려받아요.

   :::tip 자동 데이터플레인 배포 eBPF 또는 iptables 중 하나를 자동으로 배포되도록 선택할 수 있어요. :::

   • eBPF
   • iptables

   curl -O https://raw.githubusercontent.com/projectcalico/calico/v3.33.0/manifests/custom-resources-bpf.yaml
   

   curl -O https://raw.githubusercontent.com/projectcalico/calico/v3.33.0/manifests/custom-resources.yaml
   

   Calico 설치를 커스터마이즈하고 싶다면 내려받은 custom-resources.yaml 매니페스트를 로컬에서 수정하세요.

4. Calico를 설치할 매니페스트를 생성해요.

   • eBPF
   • iptables

   kubectl create -f custom-resources-bpf.yaml
   

   kubectl create -f custom-resources.yaml
   

5. 다음 명령으로 배포 상태를 관찰해요:

   watch kubectl get tigerastatus
   

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

   • eBPF
   • iptables

   예상 출력

   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
   kubeproxy-monitor               True        False         False      6m15s
   whisker                         True        False         False      3m19s
   

   예상 출력

   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
   

Policy	IPAM	CNI	Overlay	Routing	Datastore
Calico	Calico	Calico	IPIP	BGP	Kubernetes

?

탭: Manifest (v3 CRDs)

curl -O https://raw.githubusercontent.com/projectcalico/calico/v3.33.0/manifests/custom-resources-bpf.yaml

탭: Migrate to v3 CRDs

curl -O https://raw.githubusercontent.com/projectcalico/calico/v3.33.0/manifests/custom-resources.yaml

탭: Manifest

kubectl create -f custom-resources-bpf.yaml

탭: Tab 5

kubectl create -f custom-resources.yaml

탭: Tab 6

예상 출력

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
kubeproxy-monitor               True        False         False      6m15s
whisker                         True        False         False      3m19s

탭: Tab 7

예상 출력

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

탭: Tab 8

이 매니페스트는 네이티브 projectcalico.org/v3 CRD API 그룹으로 Calico를 설치해요. v3 API 그룹은 tiered policy, admission webhook, 그리고 구식 crd.projectcalico.org/v1 API 그룹에서는 사용할 수 없는 다른 기능들을 지원해요.

SECONDARY: 새 클러스터를 세팅하는 중이고 기반 Kubernetes 리소스를 커스터마이즈할 필요가 없다면 operator 사용을 권장해요. operator는 업그레이드와 스케일링을 포함해 Calico 컴포넌트의 수명 주기를 자동으로 관리해 줘요.

네이티브 projectcalico.org/v3 CRD는 기본값 적용(defaulting)에 MutatingAdmissionPolicies를 사용하기 때문에 Kubernetes 1.34 이상이 필요해요: Kubernetes 1.34/1.35에서는 beta admissionregistration.k8s.io/v1beta1 API, 1.36 이상에서는 GA admissionregistration.k8s.io/v1 API를 써요. Kubernetes 1.33 이하에서는 MutatingAdmissionPolicy가 alpha API로만 제공되며 지원되지 않아요. Kubernetes 1.34/1.35에서는 기본적으로 활성화되어 있지 않으므로 설치 전에 Kubernetes API 서버에서 MutatingAdmissionPolicy feature gate를 활성화해야 해요. Kubernetes 1.36 이상에서는 이 기능이 GA이며 기본 활성화 상태예요.

1. Calico v3 CRD 매니페스트를 내려받아요.

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

   curl https://raw.githubusercontent.com/projectcalico/calico/v3.33.0/manifests/calico-v3-crds.yaml -O
   

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

   curl https://raw.githubusercontent.com/projectcalico/calico/v3.33.0/manifests/calico-v3-crds-v1beta1.yaml -o calico-v3-crds.yaml
   

2. 파드 CIDR로 192.168.0.0/16을 쓴다면 다음 단계로 넘어가요. kubeadm에서 다른 파드 CIDR을 쓴다면 변경이 필요 없어요 — Calico가 실행 중인 설정을 기준으로 CIDR을 자동 감지해요. 그 외 플랫폼에서는 매니페스트에서 CALICO_IPV4POOL_CIDR 변수의 주석을 해제하고 선택한 파드 CIDR과 같은 값으로 설정했는지 확인하세요.

3. 필요에 맞게 매니페스트를 커스터마이즈해요.

4. 매니페스트를 적용해요.

   kubectl apply -f calico-v3-crds.yaml
   

5. admission webhook용 TLS 인증서를 생성해요.

   위에서 적용한 매니페스트에는 projectcalico.org/v3 정책 리소스에 대한 tiered RBAC enforcement를 위해 ValidatingWebhookConfiguration을 서빙하는 calico-webhooks Deployment가 포함되어 있지만, 기본으로 제공되는 TLS 자료는 없어요. 인증서가 준비되기 전에는 projectcalico.org/v3 정책 리소스에 대한 쓰기 작업이 fail closed로 실패해요.

   다음 명령은 calico-webhooks.kube-system.svc에 유효한 자체 서명 CA와 서버 인증서를 만들어요. 이미 cert-manager나 내부 PKI로 TLS를 관리하고 있다면 그것을 대신 쓰고 이 단계는 건너뛰세요.

   # Self-signed CA.
   openssl genrsa -out ca.key 2048
   openssl req -x509 -new -nodes -key ca.key -days 3650 \
       -subj "/CN=calico-webhooks-ca" -out ca.crt
   
   # Server cert with SANs for the webhook service.
   openssl genrsa -out tls.key 2048
   cat > csr.conf <<'EOF'
   [req]
   distinguished_name = req_distinguished_name
   req_extensions = v3_req
   prompt = no
   [req_distinguished_name]
   CN = calico-webhooks.kube-system.svc
   [v3_req]
   keyUsage = digitalSignature, keyEncipherment
   extendedKeyUsage = serverAuth
   subjectAltName = @alt_names
   [alt_names]
   DNS.1 = calico-webhooks.kube-system.svc
   DNS.2 = calico-webhooks.kube-system.svc.cluster.local
   EOF
   openssl req -new -key tls.key -out tls.csr -config csr.conf
   openssl x509 -req -in tls.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
       -days 365 -extensions v3_req -extfile csr.conf -out tls.crt
   

6. kube-system 네임스페이스에 웹훅 TLS 시크릿을 생성해요.

   kubectl -n kube-system create secret tls calico-webhooks-tls \
       --cert=tls.crt --key=tls.key
   

7. API 서버가 웹훅을 신뢰하도록 ValidatingWebhookConfiguration에 CA 번들을 패치해요.

   kubectl patch validatingwebhookconfiguration calico-webhooks \
       --type='json' \
       -p="[{\"op\":\"replace\",\"path\":\"/webhooks/0/clientConfig/caBundle\",\"value\":\"$(base64 -w0 < ca.crt)\"}]"
   

Policy	IPAM	CNI	Overlay	Routing	Datastore
Calico	Calico	Calico	IPIP	BGP	Kubernetes

?

탭: Tab 9

이미 구식 crd.projectcalico.org/v1 CRD를 쓰는 매니페스트 기반 Calico 설치가 있다면, 네이티브 projectcalico.org/v3 CRD로 마이그레이션할 수 있어요. 이렇게 하면 tiered policy, admission webhook, 그리고 v3 전용 기능들을 사용할 수 있게 돼요.

사전 조건

• operator가 아닌 calico.yaml 매니페스트로 설치된 Calico
• 클러스터에 대한 kubectl 접근
• 마이그레이션 컨트롤러가 포함된 최신 Calico 버전
• Kubernetes 1.34 이상. 네이티브 projectcalico.org/v3 CRD는 기본값 적용에 MutatingAdmissionPolicies를 사용하기 때문에, Kubernetes 1.34/1.35에서는 beta admissionregistration.k8s.io/v1beta1 API, 1.36 이상에서는 GA admissionregistration.k8s.io/v1 API가 필요해요. 둘 다 Kubernetes 1.33 이하에서는 사용할 수 없고, 그 버전에서는 MutatingAdmissionPolicy가 alpha로만 제공돼요. Kubernetes 1.34/1.35에서는 기본적으로 활성화되어 있지 않으므로 마이그레이션 시작 전에 Kubernetes API 서버에서 MutatingAdmissionPolicy feature gate를 활성화해야 해요. Kubernetes 1.36 이상에서는 이 기능이 GA이며 기본 활성화 상태예요.

마이그레이션 단계

1. 기존 v1 CRD와 함께 v3 CRD를 설치해요.

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

   kubectl apply --server-side --force-conflicts -f https://raw.githubusercontent.com/projectcalico/calico/v3.33.0/manifests/v3_projectcalico_org.yaml
   

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

   kubectl apply --server-side --force-conflicts -f https://raw.githubusercontent.com/projectcalico/calico/v3.33.0/manifests/v3_projectcalico_org-v1beta1.yaml
   

2. DatastoreMigration CRD를 설치해요.

   kubectl apply --server-side -f https://raw.githubusercontent.com/projectcalico/calico/v3.33.0/manifests/migration.projectcalico.org_datastoremigrations.yaml
   

3. 마이그레이션을 시작할 DatastoreMigration 리소스를 생성해요. 마이그레이션 컨트롤러가 모든 Calico 리소스를 v1 CRD에서 v3 CRD로 복사해요.

   kubectl apply -f - <<EOF
   apiVersion: migration.projectcalico.org/v1
   kind: DatastoreMigration
   metadata:
     name: v1-to-v3
   spec:
     type: APIServerToCRDs
   EOF
   

4. 마이그레이션 진행 상황을 관찰해요.

   kubectl get datastoremigration v1-to-v3 -w
   

   마이그레이션은 Pending → Migrating → Converged를 거쳐요. Converged에 도달하면 모든 리소스가 v3 CRD로 복사된 거예요.

5. 마이그레이션이 Converged에 도달하면 calico-node(그리고 calico-typha가 있다면 함께)가 v3 API 그룹을 사용하도록 설정해요.

   kubectl set env -n kube-system daemonset/calico-node CALICO_API_GROUP=projectcalico.org/v3
   

   calico-typha를 실행 중이라면 이것도 업데이트해요:

   kubectl set env -n kube-system deployment/calico-typha CALICO_API_GROUP=projectcalico.org/v3
   

6. 마이그레이션 컨트롤러가 롤아웃을 감시하다가 모든 파드가 v3 API 그룹으로 실행되면 Complete로 전환해요. kube-controllers는 새 API 그룹을 적용받도록 자동으로 재시작돼요.

   kubectl get datastoremigration v1-to-v3 -w
   

7. 마이그레이션이 Complete가 되면 오래된 v1 CRD를 정리하기 위해 DatastoreMigration 리소스를 삭제해요.

   kubectl delete datastoremigration v1-to-v3
   

   리소스의 finalizer가 리소스를 제거하기 전에 모든 crd.projectcalico.org CRD를 삭제해요.

8. DatastoreMigration 리소스가 사라지면 DatastoreMigration CRD를 삭제해요.

   kubectl get datastoremigration
   kubectl delete crd datastoremigrations.migration.projectcalico.org
   

   DatastoreMigration 리소스가 아직 존재하는 동안에는 CRD를 절대 삭제하지 마세요. 그러면 리소스까지 삭제되고, finalizer가 실행되어 단계에 따라 crd.projectcalico.org CRD를 삭제하거나 마이그레이션을 롤백해요.

9. admission webhook 리소스를 설치해요. Deployment, Service, RBAC, MutatingAdmissionPolicy 리소스, ValidatingWebhookConfiguration은 CRD와 Calico 핵심 컴포넌트와 함께 calico-v3-crds.yaml에 번들되어 있어요. yq로 웹훅 리소스만 추출해 적용하면, 클러스터의 기존 calico-node DaemonSet, kube-controllers Deployment, calico-typha Deployment(위에서 설정한 CALICO_API_GROUP env 포함)를 덮어쓰지 않아요.

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

   curl https://raw.githubusercontent.com/projectcalico/calico/v3.33.0/manifests/calico-v3-crds.yaml -O
   yq 'select(.metadata.name == "calico-webhooks" or .kind == "MutatingAdmissionPolicy" or .kind == "MutatingAdmissionPolicyBinding")' \
       calico-v3-crds.yaml | kubectl apply -f -
   

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

   curl https://raw.githubusercontent.com/projectcalico/calico/v3.33.0/manifests/calico-v3-crds-v1beta1.yaml -o calico-v3-crds.yaml
   yq 'select(.metadata.name == "calico-webhooks" or .kind == "MutatingAdmissionPolicy" or .kind == "MutatingAdmissionPolicyBinding")' \
       calico-v3-crds.yaml | kubectl apply -f -
   

10. admission webhook용 TLS 인증서를 생성해요.

    calico-webhooks Deployment는 projectcalico.org/v3 정책 리소스에 대한 tiered RBAC enforcement를 위해 ValidatingWebhookConfiguration을 서빙하지만, 기본으로 제공되는 TLS 자료는 없어요. 인증서가 준비되기 전에는 projectcalico.org/v3 정책 리소스에 대한 � 쓰기 작업이 fail closed로 실패해요.

    다음 명령은 calico-webhooks.kube-system.svc에 유효한 자체 서명 CA와 서버 인증서를 만들어요. 이미 cert-manager나 내부 PKI로 TLS를 관리하고 있다면 그것을 대신 쓰고 이 단계는 건너뛰세요.

    # Self-signed CA.
    openssl genrsa -out ca.key 2048
    openssl req -x509 -new -nodes -key ca.key -days 3650 \
        -subj "/CN=calico-webhooks-ca" -out ca.crt
    
    # Server cert with SANs for the webhook service.
    openssl genrsa -out tls.key 2048
    cat > csr.conf <<'EOF'
    [req]
    distinguished_name = req_distinguished_name
    req_extensions = v3_req
    prompt = no
    [req_distinguished_name]
    CN = calico-webhooks.kube-system.svc
    [v3_req]
    keyUsage = digitalSignature, keyEncipherment
    extendedKeyUsage = serverAuth
    subjectAltName = @alt_names
    [alt_names]
    DNS.1 = calico-webhooks.kube-system.svc
    DNS.2 = calico-webhooks.kube-system.svc.cluster.local
    EOF
    openssl req -new -key tls.key -out tls.csr -config csr.conf
    openssl x509 -req -in tls.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
        -days 365 -extensions v3_req -extfile csr.conf -out tls.crt
    

11. kube-system 네임스페이지에 웹훅 TLS 시크릿을 생성해요.

    kubectl -n kube-system create secret tls calico-webhooks-tls \
        --cert=tls.crt --key=tls.key
    

12. API 서버가 웹훅을 신뢰하도록 ValidatingWebhookConfiguration에 CA 번들을 패치해요.

    kubectl patch validatingwebhookconfiguration calico-webhooks \
        --type='json' \
        -p="[{\"op\":\"replace\",\"path\":\"/webhooks/0/clientConfig/caBundle\",\"value\":\"$(base64 -w0 < ca.crt)\"}]"
    

탭: Tab 10

데이터스토어와 노드 수에 따라 아래 링크를 골라 Calico를 설치해요.

SECONDARY: Kubernetes API 데이터스토어, 50 노드 초과 옵션은 Typha 데몬을 사용한 스케일링을 제공해요. etcd는 이미 많은 클라이언트를 처리하기 때문에 Typha가 중복되고 권장되지 않아서 etcd에는 포함되지 않아요.

• Kubernetes API 데이터스토어, 50 노드 이하로 Calico 설치
• Kubernetes API 데이터스토어, 50 노드 초과로 Calico 설치
• etcd 데이터스토어로 Calico 설치

Kubernetes API 데이터스토어, 50 노드 이하로 Calico 설치

SECONDARY: 이 옵션은 업그레이드 호환성을 위해 유지되지만, 새 클러스터는 operator 사용을 권장해요. operator는 클러스터 크기에 맞게 Calico를 자동으로 올바르게 구성해 줘요(Typha 스케일아웃 프록시 배포와 필요 시 보안 설정 포함).

1. Kubernetes API 데이터스토어용 Calico 네트워킹 매니페스트를 내려받아요.

   curl https://raw.githubusercontent.com/projectcalico/calico/v3.33.0/manifests/calico.yaml -O
   

2. 파드 CIDR로 192.168.0.0/16을 쓴다면 다음 단계로 넘어가요. kubeadm에서 다른 파드 CIDR을 쓴다면 변경이 필요 없어요 — Calico가 실행 중인 설정을 기준으로 CIDR을 자동 감지해요. 그 외 플랫폼에서는 매니페스트에서 CALICO_IPV4POOL_CIDR 변수의 주석을 해제하고 선택한 파드 CIDR과 같은 값으로 설정했는지 확인하세요.

3. 필요에 맞게 매니페스트를 커스터마이즈해요.

4. 다음 명령으로 매니페스트를 적용해요.

   kubectl apply -f calico.yaml
   

설치되는 것들의 기술적 세부 사항:

Policy	IPAM	CNI	Overlay	Routing	Datastore
Calico	Calico	Calico	IPIP	BGP	Kubernetes

?

Kubernetes API 데이터스토어, 50 노드 초과로 Calico 설치

SECONDARY: 이 옵션도 업그레이드 호환성을 위해 유지되지만, 새 클러스터는 이 방식 대신 operator로 Typha(이 매니페스트에 포함된 추가 스케일아웃 컴포넌트)를 배포하는 것을 권장해요. operator는 Typha를 배포하고 오토스케일하며, 최대 보안을 위해 per-host agent와 Typha 사이에 mTLS를 자동 구성해요. 이 매니페스트 옵션은 스케일링을 사용자에게 맡기고, 기본적으로 Typha 포트를 보안하지 않아요.

1. Kubernetes API 데이터스토어용 Calico 네트워킹 매니페스트를 내려받아요.

   curl https://raw.githubusercontent.com/projectcalico/calico/v3.33.0/manifests/calico-typha.yaml -o calico.yaml
   

2. 파드 CIDR로 192.168.0.0/16을 쓴s 다음 단계로 넘어가요. kubeadm에서 다른 파드 CIDR을 쓴다면 변경이 필요 없어요 — Calico가 실행 중인 설정을 기준으로 CIDR을 자동 감지해요. 그 외 플랫폼에서는 매니페스트에서 CALICO_IPV4POOL_CIDR 변수의 주석을 해제하고 선택한 파드 CIDR과 같은 value로 설정했는지 확인하세요.

3. calico-typha라는 Deployment의 replica 수를 원하는 값으로 수정해요.

   apiVersion: apps/v1beta1
   kind: Deployment
   metadata:
     name: calico-typha
     ...
   spec:
     ...
     replicas: <number of replicas>
   

   노드 200개당 최소 1개의 replica를 권장하고, 최대 20개를 넘지 않게 하세요. 프로덕션에서는 롤링 업그레이드와 장애의 영향을 줄이려면 최소 3개의 replica를 권장해요. replica 수는 항상 노드 수보다 작아야 롤링 업그레이드가 멈추지 않아요. 또한 Typha가 스케일에 도움이 되려면 Typha 인스턴스 수가 노드 수보다 적어야 해요.

   SECONDARY: typha_service_name을 설정하고 Typha deployment replica 수를 0으로 설정하면 Felix가 시작하지 않아요.

4. 원한다면 매니페스트를 커스터마이즈해요.

5. 매니페스트를 적용해요.

   kubectl apply -f calico.yaml
   

설치되는 것들의 기술적 세부 사항:

Policy	IPAM	CNI	Overlay	Routing	Datastore
Calico	Calico	Calico	IPIP	BGP	Kubernetes

?

etcd 데이터스토어로 Calico 설치

SECONDARY: 새 Kubernetes 설치에는 etcd 데이터스토어가 권장되지 않아요:

• etcd는 관리하고 유지해야 하는 또 하나의 컴포넌트예요.
• 일부 최신 Kubernetes 대상 기능(정책에서의 service matches 등)은 etcd 데이터스토어에서 지원되지 않아요.
• eBPF 데이터플레인 모드는 etcd 데이터스토어에서 지원되지 않아요. 일부 기능 구현에 서비스 watching을 사용하는데, etcd 데이터스토어에서는 이게 지원되지 않거든요.
• Cloud/Enterprise 버전의 Calico는 etcd 모드를 전혀 지원하지 않아서, 이 매니페스트를 쓰면 업그레이드가 막혀요.

다만 동일한 클러스터에서 OpenStack과 Kubernetes 노드를 함께 실행할 수 있는 유일한 옵션이에요.

1. etcd용 Calico 네트워킹 매니페스트를 내려받아요.

   curl https://raw.githubusercontent.com/projectcalico/calico/v3.33.0/manifests/calico-etcd.yaml -o calico.yaml
   

2. 파드 CIDR로 192.168.0.0/16을 쓴다면 다음 단계로 넘어가요. kubeadm에서 다른 파드 CIDR을 쓴다면 변경이 필요 없어요 — Calico가 실행 중인 설정을 기준으로 CIDR을 자동 감지해요. 그 외 플랫폼에서는 매니페스트에서 CALICO_IPV4POOL_CIDR 변수의 주석을 해제하고 선택한 파드 CIDR과 같은 값으로 설정했는지 확인하세요.

3. calico-config라는 ConfigMap에서 etcd_endpoints 값을 etcd 서버의 IP 주소와 포트로 설정해요.

   SECONDARY: 콤마를 구분자로 써서 여러 etcd_endpoint를 지정할 수 있어요.

4. 원한다면 매니페스트를 커스터마이즈해요.

5. 다음 명령으로 매니페스트를 적용해요.

   kubectl apply -f calico.yaml
   

설치되는 것들의 기술적 세부 사항:

Policy	IPAM	CNI	Overlay	Routing	Datastore
Calico	Calico	Calico	IPIP	BGP	etcd

?

다음 단계

필수

• calicoctl 설치 및 설정

권장 - 네트워킹

• 캡슐화 없이 full-mesh node-to-node peering을 사용하는 기본 BGP 네트워킹을 쓴다면, BGP peering 설정으로 가서 파드 간 트래픽을 흐르게 하세요.
• 네트워킹 옵션이 확실하지 않거나 캡슐화(오버레이 네트워킹)를 구현하고 싶다면 최적의 네트워킹 옵션 결정을 참고하세요.

권장 - 보안

• Calico 컴포넌트 통신 보안
• 호스트에 Calico를 설치해 호스트 보안
• Calico 네트워크 정책으로 파드 보안
• Istio 서비스 메시와 함께 Calico를 쓴다면 여기서 시작하세요: 애플리케이션 계층 정책 활성화

더 알아보기 (Learn more)

매니페스트 기반 설치 시 파드 CIDR 감지와 CALICO_IPV4POOL_CIDR 설정이 중요하니, 설치 전에 네트워킹 옵션 문서를 한 번 확인해 보세요. 설치가 끝나면 calicoctl로 정책과 IP 풀을 손쉽게 관리할 수 있어요. Istio와 함께 쓴다면 애플리케이션 계층 정책 문서도 이어서 보면 좋아요.