update: blog metadata
Update content/ko/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md Co-authored-by: Jongwoo Han <jongwooo.han@gmail.com>pull/47348/head
Junya Okabe
parent
782c1f9171
commit
2d262e5581
|
|
@ -2,6 +2,12 @@
|
|||
layout: blog
|
||||
title: '쿠버네티스에서 어려움 없이 gRPC 로드밸런싱하기'
|
||||
date: 2018-11-07
|
||||
author: >
|
||||
William Morgan (Buoyant)
|
||||
translator:
|
||||
송원석 (쏘카)
|
||||
김상홍 (국민대)
|
||||
손석호 (ETRI)
|
||||
---
|
||||
|
||||
**저자**: William Morgan (Buoyant)
|
||||
|
|
@ -15,8 +21,8 @@ date: 2018-11-07
|
|||
|
||||
|
||||
|
||||
여기 표시된 `voting` 서비스는 여러 개의 파드로 구성되어 있지만, 쿠버네티스의 CPU 그래프는 명확하게
|
||||
파드 중 하나만 실제 작업을 수행하고 있는 것(하나의 파드만 트래픽을 수신하고 있으므로)을
|
||||
여기 표시된 `voting` 서비스는 여러 개의 파드로 구성되어 있지만, 쿠버네티스의 CPU 그래프는 명확하게
|
||||
파드 중 하나만 실제 작업을 수행하고 있는 것(하나의 파드만 트래픽을 수신하고 있으므로)을
|
||||
보여준다. 왜 그런 것일까?
|
||||
|
||||
이 블로그 게시물에서는, 이런 일이 발생하는 이유를 설명하고,
|
||||
|
|
@ -27,15 +33,15 @@ gRPC 로드밸런싱을 쿠버네티스 앱에 추가하여, 이 문제를 쉽
|
|||
|
||||
먼저, 왜 gRPC를 위해 특별한 작업이 필요한지 살펴보자.
|
||||
|
||||
gRPC는 애플리케이션 개발자에게 점점 더 일반적인 선택지가 되고 있다.
|
||||
JSON-over-HTTP와 같은 대체 프로토콜에 비해, gRPC는
|
||||
극적으로 낮은 (역)직렬화 비용과, 자동 타입
|
||||
gRPC는 애플리케이션 개발자에게 점점 더 일반적인 선택지가 되고 있다.
|
||||
JSON-over-HTTP와 같은 대체 프로토콜에 비해, gRPC는
|
||||
극적으로 낮은 (역)직렬화 비용과, 자동 타입
|
||||
체크, 공식화된 APIs, 적은 TCP 관리 오버헤드 등에 상당한 이점이 있다.
|
||||
|
||||
그러나, gRPC는 쿠버네티스에서 제공하는 것과 마찬가지로
|
||||
표준(일반)적으로 사용되는 연결 수준 로드밸런싱(connection-level load balancing)을 어렵게 만드는 측면도 있다. gRPC는 HTTP/2로
|
||||
표준(일반)적으로 사용되는 연결 수준 로드밸런싱(connection-level load balancing)을 어렵게 만드는 측면도 있다. gRPC는 HTTP/2로
|
||||
구축되었고, HTTP/2는 하나의 오래 지속되는 TCP 연결을 갖도록 설계되있기 때문에,
|
||||
모든 요청은 *다중화(multiplexed)*(특정 시점에 다수의 요청이
|
||||
모든 요청은 *다중화(multiplexed)*(특정 시점에 다수의 요청이
|
||||
하나의 연결에서만 동작하는 것을 의미)된다. 일반적으로, 그것은
|
||||
연결 관리 오버헤드를 줄이는 장점이 있다. 그러나, 그것은 또한
|
||||
(상상할 수 있듯이) 연결 수준의 밸런싱(balancing)에는 유용하지 않다는 것을 의미한다. 일단
|
||||
|
|
@ -53,9 +59,9 @@ HTTP/1.1에는 TCP 연결을 순환시키게 만드는 여러 특징들이 있
|
|||
더 이상 아무것도 할 필요가 없다.
|
||||
|
||||
그 이유를 이해하기 위해, HTTP/1.1을 자세히 살펴보자. HTTP/2와 달리
|
||||
HTTP/1.1은 요청을 다중화할 수 없다. TCP 연결 시점에 하나의 HTTP 요청만
|
||||
HTTP/1.1은 요청을 다중화할 수 없다. TCP 연결 시점에 하나의 HTTP 요청만
|
||||
활성화될 수 있다. 예를 들어 클라이언트가 'GET /foo'를 요청하고,
|
||||
서버가 응답할 때까지 대기한다. 요청-응답 주기가
|
||||
서버가 응답할 때까지 대기한다. 요청-응답 주기가
|
||||
발생하면, 해당 연결에서 다른 요청을 실행할 수 없다.
|
||||
|
||||
일반적으로, 우리는 병렬로 많은 요청이 발생하기 원한다. 그러므로,
|
||||
|
|
@ -74,34 +80,34 @@ HTTP/1.1 동시 요청을 위해, 여러 HTTP/1.1 연결을 만들어야 하고,
|
|||
|
||||
|
||||
|
||||
네트워크 측면에서, L3/L4에서 결정을 내리기 보다는 L5/L7에서 결정을
|
||||
네트워크 측면에서, L3/L4에서 결정을 내리기 보다는 L5/L7에서 결정을
|
||||
내려야 한다. 즉, TCP 연결을 통해 전송된 프로토콜을 이해해야 한다.
|
||||
|
||||
우리는 이것을 어떻게 달성해야할까? 몇 가지 옵션이 있다. 먼저, 우리의 애플리케이션
|
||||
코드는 대상에 대한 자체 로드 밸런싱 풀을 수동으로 유지 관리할 수 있고,
|
||||
gRPC 클라이언트에 [로드 밸런싱 풀을
|
||||
코드는 대상에 대한 자체 로드 밸런싱 풀을 수동으로 유지 관리할 수 있고,
|
||||
gRPC 클라이언트에 [로드 밸런싱 풀을
|
||||
사용](https://godoc.org/google.golang.org/grpc/balancer)하도록 구성할 수 있다. 이 접근 방식은
|
||||
우리에게 높은 제어력을 제공하지만, 시간이 지남에 따라 파드가 리스케줄링(reschedule)되면서 풀이 변경되는
|
||||
쿠버네티스와 같은 환경에서는 매우 복잡할 수 있다. 이 경우, 우리의
|
||||
애플리케이션은 파드와 쿠버네티스 API를 관찰하고 자체적으로 최신 상태를
|
||||
애플리케이션은 파드와 쿠버네티스 API를 관찰하고 자체적으로 최신 상태를
|
||||
유지해야 한다.
|
||||
|
||||
대안으로, 쿠버네티스에서 앱을 [헤드리스(headless)
|
||||
서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)로 배포할 수 있다.
|
||||
이 경우, 쿠버네티스는 서비스를 위한 DNS 항목에
|
||||
[다중 A 레코드를 생성할 것이다](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스).
|
||||
이 경우, 쿠버네티스는 서비스를 위한 DNS 항목에
|
||||
[다중 A 레코드를 생성할 것이다](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스).
|
||||
만약 충분히 진보한 gRPC 클라이언트를 사용한다면,
|
||||
해당 DNS 항목에서 로드 밸런싱 풀을 자동으로 유지 관리할 수 있다.
|
||||
그러나 이 접근 방식은 우리를 특정 gRPC 클라이언트로를 사용하도록 제한할 뿐만 아니라,
|
||||
그러나 이 접근 방식은 우리를 특정 gRPC 클라이언트로를 사용하도록 제한할 뿐만 아니라,
|
||||
헤드리스 서비스만 사용하는 경우도 거의 없으므로 제약이 크다.
|
||||
|
||||
마지막으로, 세 번째 접근 방식을 취할 수 있다. 경량 프록시를 사용하는 것이다.
|
||||
|
||||
# Linkerd를 사용하여 쿠버네티스에서 gRPC 로드 밸런싱
|
||||
|
||||
[Linkerd](https://linkerd.io)는 [CNCF](https://cncf.io)에서 관리하는 쿠버네티스용
|
||||
*서비스 메시*이다. 우리의 목적과 가장 관련이 깊은 Linkerd는, 클러스터 수준의 권한
|
||||
없이도 단일 서비스에 적용할 수 있는
|
||||
[Linkerd](https://linkerd.io)는 [CNCF](https://cncf.io)에서 관리하는 쿠버네티스용
|
||||
*서비스 메시*이다. 우리의 목적과 가장 관련이 깊은 Linkerd는, 클러스터 수준의 권한
|
||||
없이도 단일 서비스에 적용할 수 있는
|
||||
*서비스 사이드카*로써도 작동한다. Linkerd를 서비스에 추가하는
|
||||
것은, 각 파드에 작고, 초고속인 프록시를 추가하는 것을 의미하며, 이러한 프록시가
|
||||
쿠버네티스 API를 와치(watch)하고 gRPC 로드 밸런싱을 자동으로 수행하는 것을 의미이다. 우리가 수행한 배포는
|
||||
|
|
@ -111,30 +117,30 @@ gRPC 클라이언트에 [로드 밸런싱 풀을
|
|||
|
||||
Linkerd를 사용하면 몇 가지 장점이 있다. 첫째, 어떠한 언어로 작성된 서비스든지, 어떤 gRPC 클라이언트든지
|
||||
그리고 어떠한 배포 모델과도 (헤드리스 여부와 상관없이) 함께 작동한다.
|
||||
Linkerd의 프록시는 완전히 투명하기 때문에, HTTP/2와 HTTP/1.x를 자동으로 감지하고
|
||||
Linkerd의 프록시는 완전히 투명하기 때문에, HTTP/2와 HTTP/1.x를 자동으로 감지하고
|
||||
L7 로드 밸런싱을 수행하며, 다른 모든 트래픽을
|
||||
순수한 TCP로 통과(pass through)시킨다. 이것은 모든 것이 *그냥 작동*한다는 것을 의미한다.
|
||||
|
||||
둘째, Linkerd의 로드 밸런싱은 매우 정교하다. Linkerd는
|
||||
쿠버네티스 API에 대한 와치(watch)를 유지하고 파드가 리스케술링 될 때
|
||||
로드 밸런싱 풀을 자동으로 갱신할 뿐만 아니라, Linkerd는 응답 대기 시간이 가장 빠른 파드에
|
||||
요청을 자동으로 보내기 위해 *지수 가중 이동 평균(exponentially-weighted moving average)* 을
|
||||
사용한다. 하나의 파드가 잠시라도 느려지면, Linkerd가 트래픽을
|
||||
로드 밸런싱 풀을 자동으로 갱신할 뿐만 아니라, Linkerd는 응답 대기 시간이 가장 빠른 파드에
|
||||
요청을 자동으로 보내기 위해 *지수 가중 이동 평균(exponentially-weighted moving average)* 을
|
||||
사용한다. 하나의 파드가 잠시라도 느려지면, Linkerd가 트래픽을
|
||||
변경할 것이다. 이를 통해 종단 간 지연 시간을 줄일 수 있다.
|
||||
|
||||
마지막으로, Linkerd의 Rust 기반 프록시는 매우 작고 빠르다. 그것은 1ms 미만의
|
||||
마지막으로, Linkerd의 Rust 기반 프록시는 매우 작고 빠르다. 그것은 1ms 미만의
|
||||
p99 지연 시간(<1ms of p99 latency)을 지원할 뿐만 아니라, 파드당 10mb 미만의 RSS(<10mb of RSS)만 필요로 하므로
|
||||
시스템 성능에도 거의 영향을 미치지 않는다.
|
||||
|
||||
# 60초 안에 gRPC 부하 분산
|
||||
|
||||
Linkerd는 시도하기가 매우 쉽다. 단지 —랩탑에 CLI를 설치하고— [Linkerd 시작
|
||||
지침](https://linkerd.io/2/getting-started/)의 단계만 따르면 된다.
|
||||
클러스터에 컨트롤 플레인과 "메시"
|
||||
서비스(프록시를 각 파드에 주입)를 설치한다. 서비스에 Linkerd가 즉시
|
||||
Linkerd는 시도하기가 매우 쉽다. 단지 —랩탑에 CLI를 설치하고— [Linkerd 시작
|
||||
지침](https://linkerd.io/2/getting-started/)의 단계만 따르면 된다.
|
||||
클러스터에 컨트롤 플레인과 "메시"
|
||||
서비스(프록시를 각 파드에 주입)를 설치한다. 서비스에 Linkerd가 즉시
|
||||
실행될 것이므로 적절한 gRPC 밸런싱을 즉시 확인할 수 있다.
|
||||
|
||||
Linkerd 설치 후에, 예시 `voting` 서비스를
|
||||
Linkerd 설치 후에, 예시 `voting` 서비스를
|
||||
다시 살펴보자.
|
||||
|
||||
|
||||
|
|
@ -143,14 +149,14 @@ Linkerd 설치 후에, 예시 `voting` 서비스를
|
|||
—코드를 변경하지 않았지만— 트래픽을 받고 있다. 짜잔,
|
||||
마법처럼 gRPC 로드 밸런싱이 됐다!
|
||||
|
||||
Linkerd는 또한 내장된 트래픽 수준 대시보드를 제공하므로, 더 이상
|
||||
CPU 차트에서 무슨 일이 일어나고 있는지 추측하는 것이 필요하지 않다. 다음은 각 파드의
|
||||
Linkerd는 또한 내장된 트래픽 수준 대시보드를 제공하므로, 더 이상
|
||||
CPU 차트에서 무슨 일이 일어나고 있는지 추측하는 것이 필요하지 않다. 다음은 각 파드의
|
||||
성공률, 요청 볼륨 및 지연 시간 백분위수를 보여주는
|
||||
Linkerd 그래프이다.
|
||||
|
||||
|
||||
|
||||
각 파드가 약 5 RPS를 얻고 있음을 알 수 있다. 또한,
|
||||
각 파드가 약 5 RPS를 얻고 있음을 알 수 있다. 또한,
|
||||
로드 밸런싱 문제는 해결되었지만 해당 서비스의
|
||||
성공률에 대해서는 아직 할 일이 남았다는 것도 살펴볼 수 있다. (데모 앱은 독자에 대한 연습을 위해 의도적으로
|
||||
실패 상태로 만들었다. Linkerd 대시보드를 사용하여
|
||||
|
|
@ -158,9 +164,9 @@ Linkerd 그래프이다.
|
|||
|
||||
# 마지막으로
|
||||
|
||||
쿠버네티스 서비스에 gRPC 로드 밸런싱을 추가하는 방법에
|
||||
쿠버네티스 서비스에 gRPC 로드 밸런싱을 추가하는 방법에
|
||||
흥미가 있다면, 어떤 언어로 작성되었든 상관없이, 어떤 gRPC
|
||||
클라이언트를 사용중이든지, 또는 어떻게 배포되었든지, Linkerd를 사용하여 단 몇 개의 명령으로
|
||||
클라이언트를 사용중이든지, 또는 어떻게 배포되었든지, Linkerd를 사용하여 단 몇 개의 명령으로
|
||||
gRPC 로드 밸런싱을 추가할 수 있다.
|
||||
|
||||
보안, 안정성 및 디버깅을 포함하여 Linkerd에는 더 많은 특징
|
||||
|
|
@ -170,4 +176,4 @@ gRPC 로드 밸런싱을 추가할 수 있다.
|
|||
Linkerd는 [CNCF](https://cncf.io) 프로젝트로
|
||||
[GitHub에 호스팅 되어 있고](https://github.com/linkerd/linkerd2), [Slack](https://slack.linkerd.io),
|
||||
[Twitter](https://twitter.com/linkerd), 그리고 [이메일 리스트](https://lists.cncf.io/g/cncf-linkerd-users)를 통해 커뮤니티를 만날 수 있다.
|
||||
접속하여 커뮤니티에 참여하는 즐거움을 느껴보길 바란다!
|
||||
접속하여 커뮤니티에 참여하는 즐거움을 느껴보길 바란다!
|
||||
|
|
|
|||
|
|
@ -4,6 +4,20 @@ title: "당황하지 마세요. 쿠버네티스와 도커"
|
|||
date: 2020-12-02
|
||||
slug: dont-panic-kubernetes-and-docker
|
||||
evergreen: true
|
||||
author: >
|
||||
Jorge Castro,
|
||||
Duffie Cooley,
|
||||
Kat Cosgrove,
|
||||
Justin Garrison,
|
||||
Noah Kantrowitz,
|
||||
Bob Killen,
|
||||
Rey Lejano,
|
||||
Dan “POP” Papandrea,
|
||||
Jeffrey Sica,
|
||||
Davanum “Dims” Srinivas
|
||||
translator:
|
||||
박재화(삼성SDS),
|
||||
손석호(ETRI)
|
||||
---
|
||||
|
||||
**업데이트:** _쿠버네티스의 도커심을 통한 도커 지원이 제거되었습니다.
|
||||
|
|
@ -12,10 +26,6 @@ evergreen: true
|
|||
|
||||
---
|
||||
|
||||
**저자:** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas
|
||||
|
||||
**번역:** 박재화(삼성SDS), 손석호(한국전자통신연구원)
|
||||
|
||||
쿠버네티스는 v1.20 이후 컨테이너 런타임으로서
|
||||
[도커를 사용 중단(deprecating)](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)합니다.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,12 +4,14 @@ title: '쿠버네티스 1.22: 새로운 정점에 도달(Reaching New Peaks)'
|
|||
date: 2021-08-04
|
||||
slug: kubernetes-1-22-release-announcement
|
||||
evergreen: true
|
||||
author: >
|
||||
[쿠버네티스 1.22 릴리스 팀](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.22/release-team.md)
|
||||
translator: >
|
||||
[손석호(ETRI)](https://github.com/seokho-son),
|
||||
[서지훈(ETRI)](https://github.com/jihoon-seo),
|
||||
[쿠버네티스 문서 한글화 팀](https://kubernetes.slack.com/archives/CA1MMR86S)
|
||||
---
|
||||
|
||||
**저자:** [쿠버네티스 1.22 릴리스 팀](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.22/release-team.md)
|
||||
|
||||
**번역:** [손석호(ETRI)](https://github.com/seokho-son), [서지훈(ETRI)](https://github.com/jihoon-seo), [쿠버네티스 문서 한글화 팀](https://kubernetes.slack.com/archives/CA1MMR86S)
|
||||
|
||||
2021년의 두 번째 릴리스인 쿠버네티스 1.22 릴리스를 발표하게 되어 기쁘게 생각합니다!
|
||||
|
||||
이번 릴리스는 53개의 개선 사항(enhancement)으로 구성되어 있습니다. 13개의 개선 사항은 스테이블(stable)로 졸업하였으며(graduated), 24개의 개선 사항은 베타(beta)로 이동하였고, 16개는 알파(alpha)에 진입하였습니다. 또한, 3개의 기능(feature)을 더 이상 사용하지 않게 되었습니다(deprecated).
|
||||
|
|
|
|||
|
|
@ -3,12 +3,15 @@ layout: blog
|
|||
title: "쿠버네티스 1.24: gRPC 컨테이너 프로브 베타"
|
||||
date: 2022-05-13
|
||||
slug: grpc-probes-now-in-beta
|
||||
author: >
|
||||
Sergey Kanzhelev (Google)
|
||||
translator:
|
||||
송원석 (쏘카),
|
||||
손석호 (ETRI),
|
||||
김상홍 (국민대),
|
||||
김보배 (11번가)
|
||||
---
|
||||
|
||||
**저자**: Sergey Kanzhelev (Google)
|
||||
|
||||
**번역**: 송원석 (쏘카), 손석호 (ETRI), 김상홍 (국민대), 김보배 (11번가)
|
||||
|
||||
쿠버네티스 1.24에서 gRPC 프로브 기능이 베타에 진입했으며 기본적으로 사용 가능하다.
|
||||
이제 HTTP 엔드포인트를 노출하지 않고, gRPC 앱에 대한 스타트업(startup), 활성(liveness) 및 준비성(readiness) 프로브를 구성할 수 있으며,
|
||||
실행 파일도 필요하지 않는다. 쿠버네티스는 기본적으로 gRPC를 통해 워크로드에 자체적으로(natively) 연결 가능하며, 상태를 쿼리할 수 있다.
|
||||
|
|
@ -22,7 +25,7 @@ gRPC 지원이 추가되기 전에도, 쿠버네티스는 이미 컨테이너
|
|||
TCP 연결이 성공했는지 여부를 확인하여 상태를 확인할 수 있었다.
|
||||
|
||||
대부분의 앱은, 이러한 검사로 충분하다. 앱이 상태(또는 준비성) 확인을
|
||||
위한 gRPC 엔드포인트를 제공하는 경우 `exec` 프로브를
|
||||
위한 gRPC 엔드포인트를 제공하는 경우 `exec` 프로브를
|
||||
gRPC 상태 확인에 사용하도록 쉽게 용도를 변경할 수 있다.
|
||||
블로그 기사 [쿠버네티스의 gRPC 서버 상태 확인](/blog/2018/10/01/health-checking-grpc-servers-on-kubernetes/)에서, Ahmet Alp Balkan은 이를 수행하는 방법을 설명하였으며, 이는 지금도 여전히 작동하는 메커니즘이다.
|
||||
|
||||
|
|
@ -122,7 +125,7 @@ Conditions:
|
|||
PodScheduled True
|
||||
```
|
||||
|
||||
이제 상태 확인 엔드포인트 상태를 NOT_SERVING으로 변경해 보겠다.
|
||||
이제 상태 확인 엔드포인트 상태를 NOT_SERVING으로 변경해 보겠다.
|
||||
파드의 http 포트를 호출하기 위해 포트 포워드를 생성한다.
|
||||
|
||||
```shell
|
||||
|
|
@ -177,4 +180,4 @@ Conditions:
|
|||
## 요약
|
||||
|
||||
쿠버네티스는 인기 있는 워크로드 오케스트레이션 플랫폼이며 피드백과 수요를 기반으로 기능을 추가한다.
|
||||
gRPC 프로브 지원과 같은 기능은 많은 앱 개발자의 삶을 더 쉽게 만들고 앱을 더 탄력적으로 만들 수 있는 마이너한 개선이다. 오늘 기능을 사용해보고 기능이 GA로 전환되기 전에 오늘 사용해 보고 피드백을 제공해보자.
|
||||
gRPC 프로브 지원과 같은 기능은 많은 앱 개발자의 삶을 더 쉽게 만들고 앱을 더 탄력적으로 만들 수 있는 마이너한 개선이다. 오늘 기능을 사용해보고 기능이 GA로 전환되기 전에 오늘 사용해 보고 피드백을 제공해보자.
|
||||
|
|
|
|||
Loading…
Reference in New Issue