CCA — 실리움 인증 어소시에이트 · 모의고사 · 퀴즈

CCA 모의고사 A

LabHub 에서 이어서 보기

문항 60개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

각 노드에서 도는 cilium-agent 의 역할로 옳은 것은?
1. API 서버를 대신해 파드 스케줄링을 결정합니다
2. 노드의 엔드포인트와 정책과 서비스 상태를 감시해 eBPF 맵과 프로그램을 그 노드에 맞게 갱신합니다
3. 클러스터 전체의 아이덴티티를 단독으로 할당하고 다른 노드에 배포합니다
4. kubelet 을 대신해 컨테이너 런타임에 파드 생성을 지시합니다
Cilium 이 IP 주소가 아니라 아이덴티티를 기준으로 정책을 강제하는 이유는?
1. IP 기반 규칙이 eBPF 맵에 저장될 수 없기 때문입니다
2. 쿠버네티스가 파드에 IP 를 부여하지 않기 때문입니다
3. 아이덴티티 번호가 IP 주소보다 항상 짧아 eBPF 맵 용량을 아낄 수 있기 때문입니다
4. 파드 IP 는 재스케줄마다 바뀌지만 라벨 집합은 그대로라, 라벨에서 파생한 아이덴티티를 쓰면 규칙을 다시 계산하지 않아도 되기 때문입니다
CiliumEndpoint 리소스가 나타내는 것은?
1. Cilium 이 관리하는 개별 워크로드의 네트워크 상태이며 아이덴티티와 IP 와 정책 강제 상태를 담습니다
2. 노드에 할당된 PodCIDR 대역입니다
3. 클러스터에 정의된 네트워크 정책의 목록입니다
4. Hubble 이 그 노드에서 수집한 플로우의 집계 결과입니다
Cilium 의 cluster-pool IPAM 모드에 대한 설명으로 옳은 것은?
1. 노드마다 별도의 클라우드 서브넷을 만들어야 합니다
2. kube-controller-manager 가 부여한 PodCIDR 을 그대로 씁니다
3. Cilium 이 클러스터 대역에서 노드별 블록을 잘라 나눠 주고 그 정보를 CiliumNode 에 기록합니다
4. 파드마다 클라우드 제공자의 보조 IP 를 직접 붙입니다
Cilium Operator 가 담당하는 일에 해당하지 않는 것은?
1. IPAM 풀에서 노드별 블록을 할당합니다
2. 쓰이지 않는 아이덴티티를 회수합니다
3. CiliumEndpoint 같은 리소스의 가비지 컬렉션을 수행합니다
4. 각 노드의 eBPF 프로그램을 커널에 직접 로드합니다
아이덴티티 할당 모드로 CRD 를 쓸 때와 KVStore(etcd)를 쓸 때의 차이는?
1. CRD 모드는 쿠버네티스 API 서버를 저장소로 쓰므로 별도 운영 부담이 없고, KVStore 모드는 외부 etcd 를 두어 규모가 큰 클러스터에서 API 서버 부하를 덜어 냅니다
2. CRD 모드는 L3 정책만 다루고 L7 정책은 KVStore 모드에서만 강제할 수 있습니다
3. CRD 모드는 IPv6 를 쓸 수 없습니다
4. 두 모드는 이름만 다르고 저장 위치가 동일합니다
kube-proxy 를 제거하고 Cilium 의 대체 기능을 쓸 때 반드시 지정해야 하는 값과 그 이유는?
1. 노드의 MTU 값이며, 터널 오버헤드를 계산해야 하기 때문입니다
2. Hubble 릴레이 주소이며, 플로우를 수집해야 하기 때문입니다
3. API 서버의 주소와 포트이며, kube-proxy 가 없으면 ClusterIP 로 API 서버에 닿을 방법이 없어 부팅 시 순환이 생기기 때문입니다
4. etcd 엔드포인트 목록이며, 아이덴티티를 저장소에서 조회해야 하기 때문입니다
터널 모드 대신 네이티브 라우팅을 선택했을 때 전제되어야 하는 조건은?
1. 모든 노드가 같은 커널 버전을 써야 합니다
2. 노드 사이의 하부 네트워크가 파드 CIDR 을 알고 그대로 라우팅해 줄 수 있어야 합니다
3. 모든 파드가 hostNetwork 를 써야 합니다
4. 클러스터가 단일 노드여야 합니다
VXLAN 캡슐화를 켰을 때 MTU 를 신경 써야 하는 이유는?
1. 캡슐화 헤더만큼 내부 페이로드가 줄어들어, 조정하지 않으면 큰 패킷이 조각나거나 버려져 간헐적 실패로 나타납니다
2. 캡슐화가 켜지면 커널이 MTU 를 0 으로 초기화하기 때문입니다
3. VXLAN 은 점보 프레임에서만 동작하기 때문입니다
4. MTU 값이 아이덴티티 계산에 들어가기 때문입니다
Cilium 을 기존 CNI 와 체이닝 모드로 붙이는 구성의 특징은?
1. 체이닝을 쓰면 Cilium 이 IPAM 까지 모두 넘겨받습니다
2. 체이닝 모드에서는 네트워크 정책을 쓸 수 없습니다
3. 주소 할당과 기본 연결은 기존 CNI 가 맡고 Cilium 은 그 위에서 정책과 관측 기능을 얹습니다
4. 체이닝은 두 CNI 가 각각 파드 IP 를 하나씩 부여하는 방식입니다
L7 정책을 강제할 때 Cilium 이 트래픽을 처리하는 방식은?
1. eBPF 가 HTTP 메서드와 경로까지 커널에서 직접 파싱합니다
2. 해당 트래픽만 노드의 Envoy 프록시로 우회시켜 L7 규칙을 적용하고 나머지는 eBPF 경로로 그대로 흘립니다
3. 모든 트래픽을 예외 없이 Envoy 로 보냅니다
4. 파드마다 사이드카 프록시를 자동으로 주입합니다
Cilium 이 부여하는 예약 아이덴티티가 필요한 이유는?
1. 예약 아이덴티티만 정책에서 참조할 수 있기 때문입니다
2. 라벨이 없는 파드에 임시 번호를 주기 위해서입니다
3. 노드 수만큼 아이덴티티를 미리 만들어 두기 위해서입니다
4. 호스트나 클러스터 밖 주소처럼 쿠버네티스 라벨이 없는 대상도 정책에서 가리켜야 하기 때문입니다
CiliumNetworkPolicy 와 CiliumClusterwideNetworkPolicy 의 차이로 옳은 것은?
1. 전자는 L3 만, 후자는 L7 까지 다룹니다
2. 전자는 네임스페이스에 속하고 그 안에서만 적용되며, 후자는 네임스페이스가 없어 클러스터 전체와 호스트까지 대상으로 삼을 수 있습니다
3. 전자는 allow 만, 후자는 deny 만 표현할 수 있습니다
4. 후자는 Cilium Operator 가 떠 있어야만 적용되고 그렇지 않으면 무시됩니다
어떤 파드를 선택하는 정책이 하나도 없을 때 그 파드의 트래픽은 어떻게 됩니까?
1. 모든 방향이 차단됩니다
2. ingress 만 차단됩니다
3. Cilium 이 기본 정책 템플릿을 자동으로 붙입니다
4. 모든 방향이 허용됩니다
클러스터 밖 인터넷으로 나가는 트래픽을 허용하려 할 때 쓰는 예약 엔티티는?
1. cluster
2. host
3. remote-node
4. world
toFQDNs 규칙이 동작하려면 함께 있어야 하는 것은?
1. DNS 질의를 Cilium 이 볼 수 있도록 DNS 포트에 대한 egress 허용과 DNS 가시성 규칙
2. 노드마다 별도의 DNS 서버 배포
3. kube-proxy 의 IPVS 모드 활성화와 세션 어피니티 설정
4. Hubble UI 설치
toCIDRSet 에서 except 필드가 하는 일은?
1. 지정한 대역을 명시적으로 거부하는 별도 deny 규칙을 만듭니다
2. 예외 대역의 트래픽을 로그로만 남깁니다
3. 예외 대역을 다른 정책으로 위임합니다
4. 허용 대역 안에서 특정 하위 대역을 빼내어 그 부분은 이 규칙으로 허용되지 않게 합니다
egress 정책을 처음 적용한 뒤 파드에서 서비스 이름 해석이 모두 실패합니다. 가장 가능성 높은 원인은?
1. kube-dns 로 향하는 UDP 53 egress 를 허용하지 않아 DNS 자체가 막혔습니다
2. 정책이 ingress 방향에 잘못 적용되었습니다
3. CoreDNS 파드가 아이덴티티를 받지 못했습니다
4. 파드의 resolv.conf 가 정책 적용 시 초기화되었습니다
L7 HTTP 규칙으로 특정 경로만 허용했을 때, 허용되지 않은 경로로 온 요청은 어떻게 처리됩니까?
1. TCP 연결 단계에서 차단되어 클라이언트가 연결 거부를 봅니다
2. 요청이 그대로 통과하고 감사 로그만 남습니다
3. 연결은 맺어지고 프록시가 HTTP 403 응답을 돌려줍니다
4. 클라이언트가 타임아웃될 때까지 아무 응답도 오지 않습니다
정책 감사 모드(policy audit mode)를 켜면 어떻게 됩니까?
1. 정책이 걸리지 않은 파드에도 기본 거부가 함께 적용되기 시작합니다
2. 거부될 트래픽을 실제로는 통과시키되 감사 판정으로 기록해, 정책을 강제하기 전에 영향 범위를 확인할 수 있게 합니다
3. 모든 트래픽이 즉시 차단되고 로그만 남습니다
4. L7 규칙만 강제되고 L3 규칙은 무시됩니다
같은 파드에 표준 NetworkPolicy 와 CiliumNetworkPolicy 가 함께 걸려 있습니다. 결과는?
1. 두 정책의 허용 규칙이 합집합으로 평가되며, 어느 쪽이든 그 방향을 선택하면 기본 거부가 시작됩니다
2. CiliumNetworkPolicy 가 표준 정책을 완전히 대체합니다
3. 표준 정책이 우선하고 Cilium 정책은 무시됩니다
4. 충돌로 판정되어 두 정책 모두 적용되지 않습니다
호스트 자체로 들어오는 트래픽을 정책으로 제한하려 합니다. 필요한 것은?
1. 각 노드에 iptables 규칙을 수동으로 추가합니다
2. 일반 CiliumNetworkPolicy 에 hostNetwork 파드를 선택자로 지정합니다
3. 호스트 방화벽 기능을 켜고 nodeSelector 를 쓰는 CiliumClusterwideNetworkPolicy 를 작성합니다
4. kube-proxy 를 다시 켜서 노드 포트를 관리하게 합니다
정책 강제 모드를 always 로 두면 어떤 변화가 생깁니까?
1. deny 규칙이 allow 규칙보다 항상 나중에 평가됩니다
2. 정책이 하나도 선택하지 않은 엔드포인트까지 기본 거부가 되어, 명시적 허용이 없으면 통신이 끊깁니다
3. L7 규칙이 모든 트래픽에 자동으로 적용됩니다
4. 기존 연결은 유지되고 새 연결만 검사합니다
Cilium 의 사이드카 없는 서비스 메시 모델이 사이드카 방식과 비교해 갖는 특징은?
1. L7 기능을 쓰려면 여전히 파드마다 프록시를 넣어야 합니다
2. 프록시를 아예 쓰지 않으므로 HTTP 경로 기반 라우팅은 지원하지 않습니다
3. L3 와 L4 는 eBPF 로 처리하고 L7 이 필요한 트래픽만 노드 단위 프록시가 다루므로, 파드마다 붙는 프록시 개수와 자원 소모가 줄어듭니다
4. 메시 기능이 노드가 아니라 API 서버에서 실행됩니다
프록시를 노드 단위로 공유할 때 감수해야 하는 점은?
1. 프록시 장애나 과부하의 영향 범위가 파드 하나가 아니라 그 노드의 여러 워크로드로 넓어집니다
2. 노드마다 서로 다른 Envoy 버전을 써야 합니다
3. L7 정책이 네임스페이스를 넘어 적용되지 않습니다
4. 파드가 재시작될 때마다 프록시 설정이 초기화됩니다
Cilium 으로 Gateway API 를 쓰려 할 때 필요한 것은?
1. 모든 파드에 사이드카를 주입해야 합니다
2. Gateway API CRD 를 설치하고 Cilium 의 Gateway API 지원을 켠 뒤 cilium 컨트롤러를 가리키는 GatewayClass 를 씁니다
3. 별도의 Ingress 컨트롤러를 함께 배포하고 그쪽으로 라우팅을 위임해야 합니다
4. kube-proxy 를 반드시 유지해야 합니다
CiliumEnvoyConfig 를 쓰는 상황으로 가장 적절한 것은?
1. 파드에 IP 를 할당하는 방식을 바꾸고 싶을 때
2. 노드 사이 트래픽을 암호화하고 싶을 때
3. 아이덴티티 계산에 쓰이는 라벨 목록을 클러스터 전체에서 조정하고 싶을 때
4. Gateway API 나 Ingress 로 표현되지 않는 Envoy 수준의 리스너와 라우팅 설정을 직접 넣고 싶을 때
노드 간 트래픽 암호화 방식으로 WireGuard 와 IPsec 을 비교한 설명으로 옳은 것은?
1. 둘 다 노드 사이 트래픽을 투명하게 암호화하며, WireGuard 는 설정이 단순하고 IPsec 은 규정 준수 요구가 있는 환경에서 선택됩니다
2. WireGuard 는 파드 단위, IPsec 은 노드 단위로 암호화합니다
3. IPsec 은 터널 모드에서만, WireGuard 는 네이티브 라우팅에서만 쓸 수 있습니다
4. 두 방식은 동시에 켜야 정상 동작합니다
노드 간 암호화를 켜면 얻을 수 없는 것은?
1. 노드를 오가는 파드 트래픽의 기밀성
2. 물리 네트워크 도청에 대한 방어
3. 워크로드 아이덴티티에 기반한 애플리케이션 수준의 상호 인증
4. 애플리케이션 코드 변경 없는 적용
Gateway API 의 HTTPRoute 로 두 백엔드 서비스에 트래픽을 90 대 10 으로 나누려면?
1. 서비스마다 별도의 Gateway 를 만들어야 합니다
2. backendRefs 에 두 서비스를 나열하고 각각 weight 를 지정합니다
3. 파드 레플리카 수를 9 대 1 로 맞춥니다
4. CiliumNetworkPolicy 에 비율을 지정합니다
Cilium Ingress 나 Gateway 에서 TLS 종료를 하려 할 때 필요한 것은?
1. 각 파드에 인증서를 수동으로 복사해야 합니다
2. 인증서를 ConfigMap 으로 저장해야 합니다
3. 인증서와 키를 담은 Secret 을 만들고 리소스에서 참조하면 Cilium 이 이를 읽어 Envoy 에 전달합니다
4. TLS 종료는 지원되지 않아 반드시 백엔드에서 처리해야 합니다
사이드카 메시와 비교했을 때 Cilium 모델에서 관측 데이터의 성격이 달라지는 지점은?
1. 파드 안에서 나가는 순간의 프록시 기준 지표 대신, 노드 데이터패스에서 본 플로우가 기본 관측 단위가 됩니다
2. 메트릭을 전혀 얻을 수 없습니다
3. L7 정보는 어떤 경우에도 볼 수 없습니다
4. 관측 데이터가 API 서버에만 저장되어 kubectl 로만 조회됩니다
Cilium 의 서비스 메시 기능을 도입하기 전에 확인해야 할 현실적인 제약은?
1. 메시를 켜면 기존 네트워크 정책이 무효가 되어 규칙을 다시 작성해야 합니다
2. 메시 기능은 단일 노드 클러스터에서만 지원됩니다
3. 메시를 켜면 모든 파드를 재생성해야 합니다
4. 사이드카 메시가 제공하는 세밀한 트래픽 제어 중 일부는 아직 대응 기능이 없거나 CiliumEnvoyConfig 로 직접 작성해야 합니다
hubble observe 로 특정 네임스페이스에서 거부된 트래픽만 보려 합니다. 알맞은 접근은?
1. 플로우를 모두 파일로 내린 뒤 텍스트 편집기로 검색합니다
2. 네임스페이스 필터와 판정 필터를 함께 걸어 DROPPED 플로우만 출력합니다
3. Hubble UI 에서만 가능하며 CLI 로는 걸러 낼 수 없습니다
4. 정책을 감사 모드로 바꿔야 볼 수 있습니다
hubble-relay 를 두는 이유는?
1. 플로우를 장기 보관할 데이터베이스 역할을 하기 때문입니다
2. 정책 판정을 대신 계산하기 때문입니다
3. Prometheus 지표를 생성하는 유일한 구성 요소이기 때문입니다
4. 각 노드의 에이전트가 수집한 플로우를 한곳에서 질의할 수 있도록 모아 주기 때문입니다
Hubble 의 플로우 데이터 보관에 대한 설명으로 옳은 것은?
1. 노드마다 크기가 정해진 링 버퍼에 담기므로 오래된 플로우는 밀려 사라집니다
2. etcd 에 영구 저장됩니다
3. CiliumEndpoint 리소스에 누적됩니다
4. 기본 보관 기간이 7일로 설정되어 있습니다
Hubble 지표를 Prometheus 로 수집하려 할 때 필요한 작업은?
1. 모든 파드에 Prometheus 사이드카를 붙입니다
2. hubble observe 출력을 주기적으로 파일로 저장합니다
3. Hubble 메트릭을 활성화해 지표 엔드포인트를 노출하고, 그 엔드포인트를 스크레이프 대상으로 등록합니다
4. Hubble UI 를 반드시 함께 설치합니다
플로우에 L7 정보가 보이지 않습니다. 가장 가능성 높은 이유는?
1. hubble-relay 가 L7 정보를 제거하기 때문입니다
2. 해당 트래픽에 L7 규칙이나 가시성 설정이 없어 프록시를 거치지 않기 때문입니다
3. L7 정보는 Hubble UI 에서만 볼 수 있기 때문입니다
4. eBPF 가 암호화된 트래픽만 파싱하기 때문입니다
장애 조사에 쓸 플로우를 나중에도 볼 수 있게 하려면?
1. 링 버퍼 크기를 최대로 늘리는 것으로 충분합니다
2. 정책 감사 모드를 상시 켜 둡니다
3. 노드 재부팅 주기를 늘립니다
4. 플로우 익스포트를 켜서 파일이나 로그 수집 파이프라인으로 흘려보낸 뒤 외부 저장소에 남깁니다
설치 직후 데이터패스가 정상인지 실제 트래픽으로 확인하려 합니다. 알맞은 것은?
1. kubectl get pods 로 파드가 Running 인지 봅니다
2. helm list 로 릴리스 상태를 확인합니다
3. 노드에 접속해 ping 을 수동으로 몇 번 보냅니다
4. 연결성 테스트를 실행해 테스트 워크로드를 배포하고 파드 간, 노드 간, 외부 방향 통신을 자동으로 검사합니다
cilium-config ConfigMap 의 값을 직접 수정했습니다. 반영을 위해 필요한 일은?
1. 에이전트가 다음 동기화 주기에 자동으로 반영합니다
2. API 서버를 재시작해야 합니다
3. 노드를 순차적으로 재부팅해야 합니다
4. 에이전트 파드를 재시작해야 하며, 이후 Helm 값과 어긋나지 않도록 설정을 한 곳에서 관리해야 합니다
Cilium 업그레이드 전에 preflight 를 먼저 배포하는 이유는?
1. 새 버전 이미지를 미리 내려받고 CRD 와 환경 호환성을 점검해, 실제 업그레이드 시 중단 시간을 줄이기 위해서입니다
2. 기존 정책을 자동으로 새 버전의 문법으로 변환해 두기 위해서입니다
3. 업그레이드 중 트래픽을 모두 차단해 두기 위해서입니다
4. 이전 버전의 eBPF 맵을 삭제하기 위해서입니다
kube-proxy 를 이미 쓰고 있는 클러스터에서 Cilium 의 대체 기능으로 전환할 때 안전한 순서는?
1. kube-proxy DaemonSet 을 먼저 삭제하고 그다음 Cilium 설정을 바꿉니다
2. 두 기능을 동시에 끄고 클러스터를 재부팅합니다
3. Cilium 에서 대체 기능을 켜고 정상 동작을 확인한 뒤 kube-proxy 를 제거합니다
4. 노드를 하나씩 클러스터에서 빼고 새로 조인시킵니다
cilium status 명령이 알려 주는 것은?
1. 클러스터에 있는 모든 파드의 CPU 와 메모리 사용량
2. 각 노드 에이전트의 상태와 데이터패스 모드, 그리고 컨트롤러와 구성 요소의 이상 여부
3. 적용된 네트워크 정책의 전체 내용
4. 노드의 커널 설정 파일 내용
Cilium 을 설치할 때 CRD 버전과 에이전트 버전이 어긋나면 생기는 일은?
1. 새 필드가 담긴 리소스가 거부되거나 무시되어, 정책이 의도대로 적용되지 않을 수 있습니다
2. API 서버가 기동에 실패합니다
3. 에이전트가 CRD 를 자동으로 이전 버전으로 되돌립니다
4. 모든 파드의 네트워크가 즉시 끊깁니다
ClusterMesh 를 구성하려 할 때 각 클러스터에 요구되는 것은?
1. 모든 클러스터가 같은 클라우드 제공자여야 합니다
2. 모든 클러스터가 하나의 API 서버를 공유해야 합니다
3. 클러스터마다 고유한 이름과 ID 를 가져야 하고, 노드끼리 서로의 파드 대역에 닿을 수 있어야 합니다
4. 모든 클러스터의 쿠버네티스 버전이 완전히 같아야 합니다
글로벌 서비스를 만들려면 무엇을 합니까?
1. 각 클러스터에 같은 이름과 네임스페이스로 서비스를 만들고 글로벌 어노테이션을 붙입니다
2. 한 클러스터에만 서비스를 만들고 나머지는 ExternalName 으로 참조합니다
3. clustermesh-apiserver 에 서비스 목록을 직접 등록합니다
4. 모든 파드에 원격 클러스터의 IP 를 환경변수로 넣습니다
글로벌 서비스로 묶은 뒤 클라이언트가 보는 동작은?
1. 요청이 항상 원격 클러스터로 먼저 갑니다
2. 서비스 이름 해석 결과가 클러스터마다 다른 이름으로 바뀝니다
3. 클러스터마다 별도의 ClusterIP 를 직접 지정해야 합니다
4. 기존과 같은 서비스 이름으로 접속하지만 백엔드 목록에 원격 클러스터의 파드까지 포함됩니다
clustermesh-apiserver 가 하는 일은?
1. 원격 클러스터로 가는 파드 트래픽을 모두 대신 중계합니다
2. 자기 클러스터의 아이덴티티와 엔드포인트와 서비스 정보를 다른 클러스터가 읽을 수 있도록 노출합니다
3. 클러스터 사이의 정책을 단독으로 판정합니다
4. 원격 클러스터의 API 서버를 대신합니다
ClusterMesh 환경에서 정책을 쓸 때 주의할 점은?
1. 엔드포인트 선택자에 클러스터를 지정하지 않으면 이름이 같은 다른 클러스터의 워크로드까지 함께 매칭될 수 있습니다
2. ClusterMesh 에서는 L7 정책을 쓸 수 없습니다
3. 정책은 반드시 모든 클러스터에 동일한 파일로 적용해야 합니다
4. 클러스터 와이드 정책은 ClusterMesh 에서 무시됩니다
ClusterMesh 연결 상태가 정상인지 확인하려면?
1. 각 클러스터의 파드 수가 같은지 비교합니다
2. 원격 클러스터의 kubeconfig 로 파드 목록을 조회해 봅니다
3. 노드에서 원격 파드 IP 로 ping 을 보내 봅니다
4. cilium clustermesh status 로 연결된 클러스터 수와 동기화 상태를 확인합니다
eBPF 맵이 필요한 이유는?
1. eBPF 프로그램은 커널 로그를 남길 수 없기 때문입니다
2. eBPF 프로그램은 호출 사이에 상태를 들고 있을 수 없으므로, 커넥션 추적이나 서비스 목록 같은 상태를 맵에 두고 사용자 공간과 공유합니다
3. eBPF 프로그램이 커널 메모리를 직접 할당할 수 있게 해 주기 때문입니다
4. 맵이 있어야 프로그램이 검증기를 우회할 수 있기 때문입니다
XDP 훅과 tc 훅의 차이로 옳은 것은?
1. XDP 는 egress 경로 전용이고 tc 는 ingress 경로 전용이라 방향이 갈립니다
2. XDP 는 사용자 공간에서, tc 는 커널에서 실행됩니다
3. XDP 는 드라이버 수준에서 수신 패킷을 아주 이른 시점에 처리해 드롭 성능이 뛰어나고, tc 는 조금 뒤 지점이라 커널 메타데이터를 활용한 처리에 유리합니다
4. tc 훅은 IPv4 만, XDP 는 IPv6 만 처리합니다
eBPF 검증기가 프로그램 로드를 막는 상황으로 옳은 것은?
1. 종료가 보장되지 않는 반복문이나 검사 없는 포인터 접근처럼 커널을 위험에 빠뜨릴 수 있는 코드가 있을 때
2. 프로그램이 맵을 두 개 이상 사용할 때
3. 프로그램이 C 언어로 작성되었을 때
4. 프로그램이 맵을 통해 사용자 공간과 데이터를 주고받을 때
커널 모듈 대신 eBPF 로 데이터패스를 구현할 때 얻는 이점은?
1. 커널 버전과 무관하게 어떤 기능이든 쓸 수 있습니다
2. 커널 소스를 다시 컴파일할 수 있습니다
3. 검증을 거친 샌드박스 안에서 실행되므로 잘못된 코드가 커널 전체를 무너뜨릴 위험이 크게 줄고, 재부팅 없이 기능을 갱신할 수 있습니다
4. 같은 일을 하는 사용자 공간 프로그램보다 항상 메모리를 적게 씁니다
커넥션 추적 맵이 가득 차면 어떤 증상이 나타납니까?
1. 정책 규칙이 자동으로 완화됩니다
2. 새 연결이 실패하거나 기존 항목이 일찍 회수되어 간헐적인 연결 오류로 나타나며, 맵 크기를 늘리는 것이 대응입니다
3. 에이전트가 즉시 종료됩니다
4. 새 연결의 모든 트래픽이 사용자 공간 에이전트로 우회합니다
eBPF 호스트 라우팅을 켜면 무엇이 달라집니까?
1. 파드마다 별도의 라우팅 테이블이 생깁니다
2. 모든 트래픽이 XDP 로 처리됩니다
3. 호스트 네트워크 스택의 상당 구간을 건너뛰고 eBPF 가 직접 전달해 지연과 CPU 사용이 줄어듭니다
4. 라우팅 결정이 커널에서 사용자 공간 에이전트로 넘어갑니다
Cilium 의 BGP 기능을 쓰는 목적으로 가장 적절한 것은?
1. 노드 사이 파드 트래픽을 암호화하기 위해서입니다
2. 파드 대역이나 로드밸런서 IP 를 사내 라우터에 광고해, 클러스터 밖에서 그 주소로 직접 라우팅되게 하기 위해서입니다
3. 클러스터 안의 서비스 디스커버리를 대체하기 위해서입니다
4. 노드에 공인 IP 를 자동으로 할당하기 위해서입니다
온프레미스 환경에서 LoadBalancer 타입 서비스에 IP 를 부여하려면?
1. 각 서비스에 NodePort 를 수동으로 지정합니다
2. 노드의 호스트 IP 를 서비스에 직접 기입합니다
3. kube-proxy 를 IPVS 모드로 바꿉니다
4. LB IPAM 용 IP 풀 리소스를 정의해 두면 Cilium 이 그 풀에서 주소를 할당합니다
BGP 피어링을 설정했는데 외부에서 로드밸런서 IP 로 접속되지 않습니다. 먼저 확인할 것으로 가장 적절한 것은?
1. 모든 파드를 재시작해 봅니다
2. 서비스의 셀렉터 라벨을 바꿔 백엔드가 다시 잡히는지 봅니다
3. 피어 세션이 Established 인지, 그리고 광고 대상에 그 IP 대역이 실제로 포함되어 있는지 확인합니다
4. 노드의 MTU 를 낮춰 봅니다