Traefik · 핵심 개념 · 인터랙티브 스터디

Traefik 완전 이해

EntryPoint · Router · Middleware · Service · Provider

"설정은 맞는데 왜 안 되지?"를 스스로 진단할 수 있게 됩니다.

이 자료의 사용법 (그냥 읽지 마세요)
각 섹션에는 먼저 답을 떠올린 뒤 확인하는 장치가 있습니다. 카드를 뒤집기 전에, 시뮬레이터를 선택하기 전에 — 1초라도 스스로 예측하세요. 떠올리는 그 순간이 기억을 만듭니다.

0가장 먼저 깨야 할 오해

클릭해서 뒤집기 전에 "맞다 / 틀리다"를 먼저 마음속으로 정하세요.

🧠 생성 효과: 정답을 바로 보여주지 않고 먼저 판단하게 만들면, 인지적 노력 자체가 기억 흔적을 강화합니다. "예측 → 확인"이 "읽기"보다 오래 남습니다.
💭 생각해보기
Traefik의 5가지 구성요소 중 재시작 없이 변경할 수 있는 것은 어느 것들일까요?
먼저 자신의 답을 떠올려 보세요 — 틀려도 생각 자체가 기억을 만듭니다

1요청 하나가 거치는 길

외부 요청이 Pod에 닿기까지 한 칸씩 따라가 보세요. ②~⑤는 전부 Traefik 내부에서 일어납니다.

⬆ ②~⑤ 점선 박스 = 전부 Traefik 한 프로세스 안에서 일어나는 일
START

"다음 단계" 버튼을 눌러 요청을 따라가 보세요

각 단계가 무엇을 하고, 깨지면 어떤 에러가 나는지 함께 보여줍니다.

🧠 세그멘팅 + 듀얼 코딩: 긴 경로를 한꺼번에 보여주면 작업기억이 넘칩니다. 한 단계씩 제어하며 보면 그림(시각)과 설명(언어)이 동시에 작동해 이해가 깊어집니다.
💭 생각해보기
Router가 아무것도 매칭하지 못했을 때와 백엔드 Pod가 꺼져 있을 때 — 두 경우의 에러 코드가 다릅니다. 각각 무엇이고, 왜 다를까요?
먼저 자신의 답을 떠올려 보세요 — 틀려도 생각 자체가 기억을 만듭니다

2핵심 개념 5종

Traefik이 라우팅을 처리하는 5가지 내부 개념. "이게 깨지면 어떤 에러"를 색으로 신호화했습니다.

🧠 신호 주기 + 사전 학습: 뒤의 에러 진단을 이해하려면 핵심 용어를 먼저 분리해 둬야 합니다. 각 카드에 "깨지면 나는 증상"을 색으로 신호화해 개념과 에러를 미리 연결합니다.
💭 생각해보기
왜 EntryPoint는 Dynamic config가 아니라 Static config에 정의할까요? 만약 Hot-reload가 가능하다면 어떤 문제가 생길까요?
먼저 자신의 답을 떠올려 보세요 — 틀려도 생각 자체가 기억을 만듭니다

3Static config vs Dynamic config

Traefik 설정의 가장 큰 함정 — "어떤 설정이 어디에 들어가는가". 구간을 클릭해 비교해 보세요.

📄
Static config
traefik.yaml · Helm · CLI
⚙️
Traefik 프로세스
🔄
Dynamic config
IngressRoute · Ingress · file
Static config — 재시작 필요
Dynamic config — Hot-reload
포함 내용EntryPoint(포트), Provider 연결, 인증서 리졸버, 로그/메트릭 설정
파일·방법traefik.yaml, Helm values.yaml ports 섹션, CLI flags
변경 시Traefik Pod rolling restart 필요
예시entryPoints.websecure.address: ":443"
providers.kubernetesCRD: {}
잘못 쓰면포트 자체가 안 열림 → connection refused, Provider 없으면 Router가 아예 안 생김
포함 내용Router(규칙), Middleware(변환), Service(백엔드), ServersTransport
파일·방법kind: IngressRoute(CRD), kind: Ingress(어노테이션), file provider
변경 시무중단 Hot-reload — Provider가 변경 감지 후 자동 반영, 요청 끊김 없음
예시kubectl apply -f ingressroute.yaml → 즉시 반영
잘못 쓰면규칙이 안 생기거나 오래된 규칙 남음 — 하지만 Traefik 프로세스는 살아있음
🧠 대조 사례: 헷갈리는 두 개념을 같은 틀로 나란히 놓으면 경계가 또렷이 인코딩됩니다. "재시작이 언제 필요한가"가 표 한 줄에서 드러납니다.
💭 생각해보기
kind: IngressRoute로 새 규칙을 추가했는데 반영이 안 됩니다. Static config와 Dynamic config 중 어느 쪽 문제일 가능성이 높을까요? 어디를 먼저 확인해야 할까요?
먼저 자신의 답을 떠올려 보세요 — 틀려도 생각 자체가 기억을 만듭니다

4Provider — 설정을 어디서 읽나

K8s에서 가장 많이 쓰는 두 Provider를 비교해 보세요. 탭을 클릭하면 전환됩니다.

kubernetes-ingress
kind: Ingress (K8s 표준)
kubernetes-crd
kind: IngressRoute (Traefik CRD)
리소스kind: Ingress — K8s 네이티브 표준
설정 방법어노테이션(traefik.ingress.kubernetes.io/...)으로 Traefik 기능 접근
Middleware어노테이션으로만 지정 — 표현력 제한적
TCP/UDP지원 안 됨 (HTTP만)
장점K8s 표준이라 다른 Ingress Controller로 교체 용이
단점Traefik 고급 기능(ServersTransport, Middleware 체인 등) 접근 불편
Static configproviders.kubernetesIngress: {}
리소스kind: IngressRoute, Middleware, ServersTransport 등 Traefik 전용 CRD
설정 방법YAML spec으로 직접 표현 — 어노테이션 불필요
MiddlewareMiddleware CRD를 만들고 IngressRoute에서 이름으로 참조
TCP/UDPIngressRouteTCP, IngressRouteUDP로 지원
장점Traefik 전 기능 사용 가능, 타입 검증됨, 가독성 높음
단점Traefik 전용 — 다른 Controller 교체 시 YAML 재작성 필요
Static configproviders.kubernetesCRD: {}
🧠 대조 사례: 같은 틀로 나란히 놓아야 "무엇이 다른가"가 명확히 인코딩됩니다. 어노테이션 방식과 CRD 방식의 경계가 표 한 줄씩에서 드러납니다.
💭 생각해보기
Middleware CRD를 prod 네임스페이스에 strip-prefix라는 이름으로 만들었습니다. default 네임스페이스의 IngressRoute에서 이 Middleware를 참조하려면 어떤 형식으로 써야 할까요?
먼저 자신의 답을 떠올려 보세요 — 틀려도 생각 자체가 기억을 만듭니다

5에러 진단 시뮬레이터

증상을 하나 고르면, 어느 레이어 문제인지 아래에서 위로 짚어드립니다. 고르기 전에 "이건 어느 단계?"를 먼저 예측하세요.

어떤 증상을 만났나요?
404
page not found (text/plain)
502
Bad Gateway
⚠
middleware not found
🧠 인출 연습 + 즉각 피드백: "증상→원인" 매핑을 수동으로 읽는 대신, 선택이라는 인출 행위를 거친 뒤 정답 경로를 봅니다. 테스트 효과 메타분석 g≈0.50.

6능동 회상: 카드 & 퀴즈

먼저 답을 입 밖으로 말해본 뒤 카드를 여세요. 보기 전에 떠올린 0.5초가 기억을 만듭니다.

플래시카드 (클릭해서 정답 확인)

객관식 퀴즈

🧠 인출 연습 + 바람직한 어려움(Bjork): 떠올리기는 재읽기보다 느리고 어렵게 느껴지지만, 그 어려움이 저장 강도를 높입니다. 며칠 뒤 다시 풀면(간격 반복) 효과가 배가됩니다.

7막히면: 레이어별 진단 순서

에러가 나면 아래(기초)에서 위로 한 칸씩 올라가며 확인하세요. 각 칸을 클릭하면 명령어가 나옵니다.

🧠 청킹 + 절차 자동화: 흩어진 명령어를 "1→6 사다리"라는 하나의 절차로 묶으면, 다음에 막혔을 때 개별 명령이 아니라 "순서"라는 단일 단위로 인출됩니다.

8한 장 요약 (다음에 이것만 봐도 됨)

Client ─▶ EntryPoint(port) ─▶ Router(Host/Path) ─▶ Middleware(chain) ─▶ Service(LB) ─▶ Pod