일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 스프링
- 조건문
- Apollo
- LangChain
- mysql
- restapi
- HTTP
- java11
- graphql
- Scanner
- 스프링부트
- k8s
- java
- Spring
- 서버
- 프로그래머스
- ai
- 자바
- mongodb
- bufferdreader
- Docker
- MapReduce
- redis
- nodejs
- eof
- puppeteer
- 백준알고리즘
- Android
- TCP
- Mongoose
- Today
- Total
목록k8s (2)
자라나라 개발머리
k8s에는 service라는 리소스가 있습니다. service는 여러개의 pod를 하나의 Ip로 접근할 수 있도록 하는 역할을 합니다. 그럼 service는 요청들을 어떤 방식으로 로드 밸런싱할까요? 저는 당연히 round-robin 방식으로, 균등하게 각 pod에 전달할 줄 알았습니다. 하지만 k8s는 round-robin 방식으로 트래픽을 전달하지 않고 있었습니다! 이에 대해 리서치하다가 자세하고 친절하게 적은 외국 블로그 글을 발견했습니다. 그래서 오늘은, 그 블로그 글을 정리하여 service의 로드 밸런싱 전략에 대해 설명해보겠습니다. service의 로드 밸런싱 전략 service로 만든 ip 주소들은, kube-proxy에서 사용됩니다. kube-proxy는 모든 service의 IP 주소 ..
node:16-slim puppeteer 13.5.0 k8s 에러 상황 내가 원했던 동작은 특정 페이지에서 스크롤을 내리는 동작이었다. 스크롤을 내리면 새로운 정보가 로딩되는 페이지인데, 특정 조건에 걸릴 때 까지 스크롤을 반복하는 동작을 구현했다. 로컬에선 잘 실행되는 코드가 k8s에 띄워서 실행하면 중간에 동작이 멈추고 무한 대기에 빠진다. 동작이 멈추는 시점은 동작할 때 마다 다른 시점에 발생한다. 로컬에서와 달리 페이지 동작 상태를 눈으로 확인할 수도 없으니, 현재 상태를 파악하기가 어려워 원인을 찾기도 어려웠다. 퍼펫티어가 문제인건지, 네트워크 상태가 문제인건지, 페이지가 문제인건지 무수한 경우의 수가 있으니 정말 갖가지 시도를 해본 것 같다. 에러 파악 과정 에러 원인 가정 짐작할 수 있는 에..