N° 01 — 목록

'sidecar' (2)

  1. Tech Artifacts/K8s Networking

    K8s Networking - 10. service-mesh concepts

    왜 모든 앱에 "트래픽 관리 코드"를 중복해서 짜야 할까 — 서비스 메시가 푸는 문제마이크로서비스가 30개로 늘었다. 각 서비스마다 같은 코드가 반복됐다: 재시도, 타임아웃, 서킷 브레이커, 메트릭, 분산 추적, mTLS 인증. 개발자는 비즈니스 로직보다 이 인프라 코드*를 더 짜고 있었다. 그리고 언어마다(Java/Go/Node) 각자 다시 구현했다. 한 팀이 물었다: "이걸 *앱 밖으로 뺄 수 없나?" 서비스 메시(service mesh)가 바로 그 답이다.이 글이 푸는 것은: 서비스 메시가 어떤 문제를 풀고, 사이드카 패턴으로 어떻게 앱 코드에서 인프라 로직을 빼내는가다. 이해하면 11장(Istio)/12장(Cilium 메시)의 설계가 보인다.서비스 간 통신에 필요한 것 — 그리고 그것이 앱마다 중..

    · 댓글
  2. Tech Artifacts/Kubernetes

    Kubernetes - 04. pod

    왜 컨테이너 하나만 띄우면 "Pod"라는 포대까지 필요한가처음 Kubernetes를 배우는 사람은 거의 다 같은 의문을 갖는다. 컨테이너를 하나 띄우고 싶을 뿐인데, 왜 kind: Pod에 containers: 배열을 넣고 그 안에 컨테이너를 적어야 하나? Docker처럼 그냥 컨테이너를 실행하면 안 되나?이 질문은 사소해 보이지만 Kubernetes의 가장 근본적인 설계 결정을 건드린다. 왜 Kubernetes는 컨테이너를 직접 다루지 않고 Pod라는 한 겹 더 두른 단위를 배포의 최소 단위로 삼았는가? 이 글의 답은 단순하다 — Pod는 컨테이너가 아니라 "함께 죽고 함께 사는 컨테이너들의 묶음"이며, 이 묶음이 공유하는 것(네트워크·스토리지·생명)이 Kubernetes의 모델을 만든다.Pod는 컨테..

    · 댓글
Tech Artifacts/K8s Networking

K8s Networking - 10. service-mesh concepts

왜 모든 앱에 "트래픽 관리 코드"를 중복해서 짜야 할까 — 서비스 메시가 푸는 문제마이크로서비스가 30개로 늘었다. 각 서비스마다 같은 코드가 반복됐다: 재시도, 타임아웃, 서킷 브레이커, 메트릭, 분산 추적, mTLS 인증. 개발자는 비즈니스 로직보다 이 인프라 코드*를 더 짜고 있었다. 그리고 언어마다(Java/Go/Node) 각자 다시 구현했다. 한 팀이 물었다: "이걸 *앱 밖으로 뺄 수 없나?" 서비스 메시(service mesh)가 바로 그 답이다.이 글이 푸는 것은: 서비스 메시가 어떤 문제를 풀고, 사이드카 패턴으로 어떻게 앱 코드에서 인프라 로직을 빼내는가다. 이해하면 11장(Istio)/12장(Cilium 메시)의 설계가 보인다.서비스 간 통신에 필요한 것 — 그리고 그것이 앱마다 중..

Tech Artifacts/Kubernetes

Kubernetes - 04. pod

왜 컨테이너 하나만 띄우면 "Pod"라는 포대까지 필요한가처음 Kubernetes를 배우는 사람은 거의 다 같은 의문을 갖는다. 컨테이너를 하나 띄우고 싶을 뿐인데, 왜 kind: Pod에 containers: 배열을 넣고 그 안에 컨테이너를 적어야 하나? Docker처럼 그냥 컨테이너를 실행하면 안 되나?이 질문은 사소해 보이지만 Kubernetes의 가장 근본적인 설계 결정을 건드린다. 왜 Kubernetes는 컨테이너를 직접 다루지 않고 Pod라는 한 겹 더 두른 단위를 배포의 최소 단위로 삼았는가? 이 글의 답은 단순하다 — Pod는 컨테이너가 아니라 "함께 죽고 함께 사는 컨테이너들의 묶음"이며, 이 묶음이 공유하는 것(네트워크·스토리지·생명)이 Kubernetes의 모델을 만든다.Pod는 컨테..

은 관리자 편집기 위젯 라벨이 됨 -->