일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 |
- container runtime
- opentelemetry
- 종결 조건
- Instrumentation libraries
- master node
- k8s
- 장단기 금리 차
- smart money
- 워커 노드
- 컨테이너 런타임
- 마스터 노드
- controller manager
- worker node architecutre
- Branch
- 워커 노드 구조
- GIT
- 쿠버네티스 네터워크
- 왜 쿠버네티스
- 쿠버네티스 구조
- worker node
- 기저조건
- Data store
- Dag
- Kubernetes User
- COMMIT
- 쿠버네티스 유저
- Kubernetes Architecture
- 오픈텔레미트리
- 깃
- 쿠버네티스
- Today
- Total
개발과 잡지식
Kubernetes 06 - Kubernetes Architecture 3 본문
Introduction to Kubernetes
이미지 출처 : https://kubernetes.io/docs
Will Be Check
- Discuss the Kubernetes architecture.
- Explain the different components for master and worker nodes.
- Discuss about cluster state management with etcd.
- Review the Kubernetes network setup requirements.
Kubernetes Architecture
Networking Challenges
각기 분리된 마이크로 서비스는 네트워크에 엄청나게 영향을 받습니다. 네트워킹은 이해하기도 어렵고 실행하기도 어렵습니다.
쿠버네티스도 마찬가지지만 몇 가지 고전적인 네트워킹 문제를 해결해서 모놀리식처럼 타이트하게 연결될 수 있도록 해야 합니다.
- Container-to-container communication inside Pods
- Pod-to-Pod communication on the same node and across cluster nodes
- Pod-to-Service communication within the same namespace and across cluster namespaces
- External-to-Service communication for clients to access applications in a cluster.
Container-to-container communication inside Pods
컨테이너 런타임은 각각의 컨테이너가 격리된 네트워크 공간을 만들어 줍니다. 이러한 격리된 네트워크 공간은 Network namespace라고 부르며 이 공간은 컨테이너 간 또는 호스트 운영 체제와 공유할 수 있습니다.
Pod가 시작되면 컨테이너 런타임은 pause 컨테이너를 통해서 pod의 name space를 초기화해줍니다.
Pod내에서 실행되는 모든 컨테이너는 pause container의 네트워크 네임스페이스를 공유하며 localhost를 통해서 서로 통 신 할 수 있습니다.
Pod-to-Pod Communication Across Nodes
노드와 상관없이 모든 Pod들은 서로 통신할 수 있는데 흔히 네트워크 상에서 볼 수 있는 NAT( Network Address Translation)을 사용하지는 않는다.
Pod를 VM이라고 생각하면 편하다. VM 마다 Network에서 작동할 수 있도록 interface가 있으며 각각의 고유 IP주소를 가지고 있다(IP per Pod라고 불린다. Pod 당 하나의 IP를 가지고 있다.)
Pod가 시작되면 Pod의 네트워크 네임 스페이스를 만들기 위한 목적으로 만 Container Runtime에 의해 특수 Pause 컨테이너가 초기화됩니다. 사용자 요청을 통해 생성되고 Pod 내에서 실행되는 모든 추가 컨테이너는 Pause 컨테이너의 네트워크 네임 스페이스를 공유하므로 모두 localhost를 통해 서로 통신할 수 있습니다.
다시 말하자면 Pod는 하나의 VM이고 VM안에 여러 port에 하나하나 동작하는 애플리케이션처럼 container가 존재한다.
그렇다면 어떻게 가상 머신의 한 포트에서 동작하는 애플리케이션과 같은 컨테이너가 쿠버네티스의 네트워크와 융합돼서 작동되는 게 가능할까? 그것은 CNI라는 때문이다.
CNI는 플러그인이 컨테이너에 대한 네트워크 구성할 수 있도록 하는 사양 및 라이브러리가 닮 겨 있습니다.
CNI를 통해서 작동하는 여러 플러그인을 통해서 쿠버네티스의 네트워크 안에서 container들이 융합될 수 있습니다.
자세한 내용은 => https://kubernetes.io/docs/concepts/cluster-administration/networking/
Pod to External World Communication
Services, Ingress 등을 통해서 외부의 network와 communication이 가능합니다. 이 내용은 추후 자세히 다루겠습니다.
다음 글에서 아키텍처에 대해서 전반적으로 요약해서 올리고 Check 문제를 풀어보겠습니다.
'micro service > kubernetes(k8s)' 카테고리의 다른 글
Kubernetes 05 - Kubernetes Architecture 2 (0) | 2021.01.15 |
---|---|
Kubernetes 04 - Kubernetes Architecture 1 (0) | 2021.01.12 |
Kubernetes 03 - From Monolith to Microservices - Part 2 (0) | 2021.01.10 |
Kubernetes 02 - From Monolith to Microservices (0) | 2021.01.09 |
Kubernetes 01 - Container Orchestration (0) | 2021.01.08 |