kubenet : 노드에 대한 pod ip가 물리적으로 private ip를 갖지 않는다. NATing 되어서 별도의 네트워크를 가지고 있다고 생각하면 된다. 그래서 각각의 pod끼리 통신을 하거나, Azure 네트워크 내에서 통신, 혹은 외부 인터넷과 통신을 할 때 노드의 NAT 테이블을 통해 라우팅 되어서 통신을 하게 된다. kubenet의 제한 사항 & 고려 사항 Kubenet 디자인에는 추가 홉이 필요하며 이는 Pod 통신에 약간의 대기 시간을 추가합니다. kubenet을 사용하려면 경로 테이블 및 사용자 정의 경로가 필요하며 이는 작업에 복잡성을 더합니다. Kubenet 디자인으로 인해 kubenet에 직접 Pod 주소 지정은 지원되지 않습니다.ㄴ 따라서 통신을 할 때는 로드 밸런서를 통하거나 ..

https://www.youtube.com/watch?v=f8zCw5KlmPo 기본적으로 AKS는 무료 버전이다. 무료버전이기 때문에 SLO는 제공하지만 SLA는 제공하지 않는다. SLO : 99.5% 안정성 보장. 하지만 이슈가 있을 때 돈을 개런티해주지는 않는다. 새로 출시된 기능이 업데이트 SLA : 0.1$ / hour -> 하루에 2.4$ 가용성 영역이 있는 곳은 99.95% 가용성 영역이 없는 곳은 99.9% SLO와 SLA의 차이가 뭐냐? Control Plane에 과금이 되느냐 안되느냐의 차이다. Control Plane에는 API Server, Scheduler, etcd 등의 컴포넌트들이 있다. SLA를 쓰면, 빅클러스터를 사용했을 때 각각의 컴포넌트들이 Auto Scale이 된다. 따..

https://medium.com/@jerub/service-level-indicators-in-practice-6a1125e24bee

선 요약 메시지 큐의 목적 : 클라이언트와 작업 서버 사이에 버퍼를 두어, 클라이언트의 요청과 요청에 대한 작업을 독립적으로 구성하기 위한 것이다. 이게 무슨 뜻일까? 요청 : 사용자의 요청. 작업 : 사용자의 요청을 처리하는 작업. 이렇게 정의하고 시작하자. 오케이. 그럼 요청과 작업을 독립적으로 구성하지 않으면 무슨 문제가 생길까? 예를 들어서, 카카오톡 서버의 아키텍쳐를 설계한다고 하자. 그리고 천만명이 1초에 한 번씩 메세지를 보낸다고 하자. 중간에 버퍼가 없다면, 요청이 곧바로 API 서버에 전달되기 때문에 결국 1초에 천만 request가 동시에 작업 서버에 전달된다. 이는 아무리 좋은 서버라고 해도 당연히 감당하기 쉽지 않다. (참고. 스택 오버 플로우는 2013년 한 해 동안 방문한 천만 ..

https://sre.google/sre-book/foreword/ Google - Site Reliability Engineering Foreword Google's story is a story of scaling up. It is one of the great success stories of the computing industry, marking a shift towards IT-centric business. Google was one of the first companies to define what business-IT alignment meant in practice, a sre.google

https://bcho.tistory.com/m/1328 SRE #3-SRE의 주요 지표 SLI/SLO (Service Level Indicatior, Service Level Objectives) SRE #3-SRE 주요 지표 (SLI/SLO) 조대협 (http://bcho.tistory.com) 이글은 앞글 (https://bcho.tistory.com/1327)과 연결 됩니다. 앞에 까지 SRE가 무엇이고, SRE가 하는일은 무엇이며, 어떻게 그 일을 수행 하.. bcho.tistory.com 정말 잘 설명해주신 글이 있어서 링크 달았다. SRE에 대한 구글의 관점을 번역해주셨다.