| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
- convolution
- CuDNN
- GPU
- stl
- CUDA
- sycl
- cloud
- kubernetes
- flash_memory
- DRAM
- SpMM
- 딥러닝
- 클라우드
- quantum_computing
- 쿠버네티스
- jhDNN
- C++
- Semiconductor
- 반도체기초
- POD
- 양자역학의공준
- FPGA
- HA
- Compression
- nvidia
- dnn
- 반도체
- jhVM
- deep_learning
- Qubit
- Today
- Total
목록LoadBalancer (3)
Computing
Pod 네트워크 (4) : LoadBalancer와 MetalLB (load balancing 개념, MetalLB 역할)
이전글 - Pod 네트워크 (1) : Service 필요성과 개념, 종류 (ClusterIP, NodePort, LoadBalancer) - Pod 네트워크 (2) : Service 내부 구현 분석 (kube-proxy와 iptables) - Pod 네트워크 (3) : kube-proxy와 CNI plugin 차이 이전 포스터에서 Pod를 내, 외부 네트워크에 공개하는 Service 개념에 대해서 정리하였다. 이번 포스터에서는 Service들 중 LoadBalancer type Service의 개념과 이것을 사용하기 위해 필요한 MetalLB에 대해서 정리하고자 한다. Load Balancing과 Load Balancer Load Balancing, 부하 분산[2]은 여러 개의 프로세싱 유닛(CPU co..
Pod 네트워크 (2) : Service 내부 구현 분석 (kube-proxy와 iptables)
이전글 - Pod 네트워크 (1) : Service 필요성과 개념, 종류 (ClusterIP, NodePort, LoadBalancer) 이전 글에서 쿠버네티스의 서비스 리소스의 필요성과 그 개념에 대하여 정리하였다. 쿠버네티스 서비스는 파드들에 네트워크 접근할 수 있도록 변하지 않는 Private or Public IP를 제공하는 리소스이다. 사실 서비스 없이도 파드와 네트워크 통신할 수 있지만, 그 과정이 복잡하고 구현하기 까다롭다. (Iptables rule, routing table 설정 등을 Pod 정보가 변할 때마다 개발자가 직접 계속해서 관리해줘야 할 것이다.) 쿠버네티스는 서비스라는 추상화된 개념을 도입하여 이를 누구나 쉽게 이용할 수 있도록 제공한다. Fig 1.은 Service 개념을 ..
Pod 네트워크 (1) : Service 필요성과 개념, 종류 (ClusterIP, NodePort, LoadBalancer)
파드 통신 예시 및 Service의 필요성 쿠버네티스 클러스터에서 애플리케이션(워크로드)은 파드 단위로 실행된다. 애플리케이션은 하나 이상의 파드들로 구성될 수 있는데, 간단한 웹애플리케이션 예시를 들면 Java spring 웹애플리케이션 로직을 담당하는 파드 3개, 데이터 저장을 위한 DB 파드 하나로 구성될 수 있다. Fig 1.과 같이 모든 파드는 쿠버네티스 클러스터 안에서 가상 IP 하나를 부여받는다. 이 가상 IP는 쿠버네티스 클러스터 안에서 유일하며, 쿠버네티스 클러스터 내에서만 유효하다. 이 가상 IP를 통해 같은 쿠버네티스 클러스터 내의 파드들끼리는 통신이 가능하다. 예를 들면 Fig 1.에서 Pod A가 Pod C와 통신하기 위해서 10.1.2.1로 패킷을 보내는 것이 가능하다. 문제는 ..