구성요소를 하나씩 내렸더니 멈춘 것과 버틴 것

목표

진짜 Cilium 1.20.1 에서 cilium agent·operator·cilium-envoy·hubble-relay 가 각각 무엇을 맡는지, 하나씩 내려 보고 확인합니다.
먼저 cluster-pool IPAM 과 CiliumIdentity 가 어디에 기록되는지 읽고, 구성요소가 없는 동안 새 파드·L7 요청·흐름 조회·기존 트래픽이 어떻게 되는지를
기록한 뒤 되돌립니다.

왜 중요한가

"Cilium 이 죽었다" 는 신고는 어느 구성요소가 멈췄느냐에 따라 전혀 다른 사고입니다. 오퍼레이터는 클러스터에 한 번 하면 되는 일을 맡아
잠시 없어도 전달·정책 결정에 끼어들지 않습니다. envoy 가 없으면 L7 규칙이 걸린 경로만 멈춥니다. relay 가 없으면 여러 노드를 한곳에서
조회하는 길만 끊깁니다. 에이전트가 없으면 이미 적재된 데이터패스는 계속 돌지만 새 파드는 네트워크를 받을 수 없어 스케줄이 막힙니다.

구성요소를 내리는 단계는 관측을 기록한 뒤 반드시 되돌립니다(에이전트만 6단계에서 내리고 7단계에서 되돌립니다). 복구 뒤 전체 채점은
그때의 기록을 파드 uid·신원·흐름 시각·복구된 파드의 생성 시각과 대조하므로, 기록은 반드시 내려간 동안 만드세요.

환경 준비에 약 5분이 걸립니다. 6단계와 7단계 사이에는 에이전트가 없어 에이전트 명령이 동작하지 않습니다. 세션이 끝나면 /root/cca-parts 의 파일은 사라집니다.

단계

1. kubectl apply -f /opt/fixtures/cca-components/workload.yaml 로 cca-parts 에 app(레플리카 2)·api-l7·client 를 띄우세요. /root/cca-parts/ipam.json 에 기록합니다 — ipam_mode·cluster_pool·mask_size(cilium-config 의 ipam, cluster-pool-ipv4-cidr, cluster-pool-ipv4-mask-size 는 숫자), node_pod_cidrs(CiliumNode 의 spec.ipam.podCIDRs 목록), status_pool·capacity(에이전트 cilium-dbg status 의 IPAM 줄에서 allocated from 뒤의 대역과 / 뒤의 숫자), router_ip(VM 의 cilium_host 장치 IPv4), pods(cca-parts 파드 4개의 이름 → IP 사전).
2. app 레플리카 두 파드와 client 의 CiliumEndpoint 신원 번호를 비교하고, app 의 CiliumIdentity 객체를 읽으세요. /root/cca-parts/identity.json 에 app_identity, app_endpoints(app 파드 이름 2개), client_identity, security_labels(그 CiliumIdentity 의 security-labels 를 키=값 문자열로 정렬한 목록), allocation_mode(cilium-config 의 identity-allocation-mode) 를 기록합니다.
3. cilium-operator 를 replicas 0 으로 내리고 오퍼레이터 파드가 모두 사라질 때까지 기다리세요. 그 상태에서 cca-parts 에 파드 born-no-operator(이미지 client 와 같은 curl, 라벨 born=no-operator, 명령 sleep 86400)를 만들고 Ready 가 되면 /root/cca-parts/operator-down.json 에 operator_replicas(그때 Deployment 의 spec.replicas, 숫자), pod_uid, pod_ip, identity(그 파드의 CiliumEndpoint 신원) 를 기록합니다. 기록한 뒤 오퍼레이터를 1 로 되돌리고 available 이 될 때까지 기다립니다.
4. cca-parts 에 CiliumNetworkPolicy l7-get 을 만드세요 — endpointSelector app=api-l7, ingress 한 항목: fromEndpoints app=client, toPorts 에 TCP "8080" 과 rules.http [{method: GET, path: /allowed}]. client 에서 api-l7 의 /allowed 가 200, /secret 이 403 인 것을 확인한 뒤, kube-system 의 cilium-envoy DaemonSet 에 존재하지 않는 nodeSelector cca-lab/envoy: "off" 를 더해 envoy 파드를 치웁니다. 그동안 client 에서 api-l7 /allowed(5초 제한)와 app 서비스(http://app:8080/)를 요청하고 에이전트 안 hubble 로 client→api-l7 흐름을 읽어 /root/cca-parts/envoy-down.json 에 l7_code, plain_code(HTTP 코드 문자열, 응답 없음은 "000"), flows(client→api-l7 흐름 compact 줄 목록) 를 기록합니다. 그다음 그 nodeSelector 키를 제거해 envoy 를 되돌리고 /allowed 가 다시 200 이 될 때까지 기다립니다.
5. kube-system 의 hubble-relay 를 replicas 0 으로 내리세요. VM 셸에서 hubble status --server <hubble-relay 서비스 ClusterIP>:80 이 실패하는 오류 한 줄을, 에이전트 안에서 hubble observe --last 5 -o compact 의 흐름 줄과 hubble status 의 Current/Max Flows 줄을 읽어 /root/cca-parts/relay-down.json 에 relay_error, local_flows(목록), local_status 로 기록합니다. 그다음 relay 를 1 로 되돌리고 릴레이 경유 status 가 성공할 때까지 기다립니다.
6. kube-system 의 cilium DaemonSet 에 nodeSelector cca-lab/agent: "off" 를 더해 에이전트 파드를 치우세요(이 단계에서는 되돌리지 않습니다). 파드가 사라지면 노드 taint 를 확인하고, client 에서 app 서비스를 요청한 뒤, cca-parts 에 curl 파드 orphan(명령 sleep 86400)을 만들어 FailedScheduling 이벤트를 기다립니다. /root/cca-parts/agent-down.json 에 existing_code(client→app 코드 문자열), taint(노드에 걸린 cilium taint 의 key:effect), orphan_uid, orphan_phase, reason·message(orphan 의 FailedScheduling 이벤트) 를 기록합니다.
7. cilium DaemonSet 에서 nodeSelector 키 cca-lab/agent 를 제거해 에이전트를 되돌리세요. 에이전트가 Ready 가 되고 노드의 agent-not-ready taint 가 사라지며 orphan 이 스케줄(PodScheduled=True)될 때까지 폴링한 뒤 /root/cca-parts/restore.json 에 taint_removed(true/false), orphan_scheduled_at(orphan 의 PodScheduled 조건 lastTransitionTime), agent_pod(새 에이전트 파드 이름) 를 기록합니다.
8. /root/cca-parts/report.txt 에 키=값 여덟 줄을 씁니다 — ipam_mode, node_pod_cidr, identity_allocation_mode, without_operator_new_pod(born-no-operator 의 지금 phase), without_envoy_l7·without_envoy_plain(envoy-down.json 의 두 코드), without_agent_existing·without_agent_new_pod(agent-down.json 의 existing_code 와 orphan_phase). 값은 기록 파일·지금 설정과 일치해야 합니다.

참고

• 구성요소 개요(agent·operator·Hubble relay): https://docs.cilium.io/en/v1.20/overview/component-overview/
• Cilium Operator 의 역할과 없을 때 생기는 일: https://docs.cilium.io/en/v1.20/internals/cilium_operator/
• Cluster Scope IPAM(cluster-pool): https://docs.cilium.io/en/v1.20/network/concepts/ipam/cluster-pool/
• Envoy DaemonSet 모드: https://docs.cilium.io/en/v1.20/security/network/proxy/envoy/
• 노드 taint 와 관리되지 않는 파드: https://docs.cilium.io/en/v1.20/installation/taints/
• 에이전트 명령: kubectl -n kube-system exec ds/cilium -c cilium-agent -- cilium-dbg status / hubble observe.

단계 8개

1. 파드 주소는 어디서 잘라 온 것인가
2. 레플리카 둘은 신원 하나를 나눠 쓴다
3. 오퍼레이터가 없는 동안 태어난 파드
4. envoy 를 치웠더니 L7 경로만 멈췄다
5. 릴레이가 죽어도 노드는 흐름을 모으고 있었다
6. 에이전트를 치웠는데 기존 요청은 계속 된다
7. 에이전트가 돌아오자 taint 가 풀린다
8. 누가 멈추면 무엇이 멈추는가