반응형
leader-elector를 알아보자
목표
node 3대에 kube-state-metrics를 pod가 아닌 containerd로 배포하고
이 중 한개의 모드에서만 kube-state-metrics container를 리더로 설정해서 동작하고
나머지 2개의 노드에서는 slave로 대기하도록 구성하고 싶다.
관련 기능을 알아보다가 leader-elector를 확인했다.
한번 알아보고 적용할 수 있는지 확인해보자
leader-elector란?
leader-elector 컨테이너는 리더를 선택하는 메커니즘을 구현한 컨테이너임.
일반적으로 kubernetes와 같은 컨테이너 오케스트레이션의 클러스터 내에서
여러 노드 간의 통신을 통해 리더를 선출하는 데 사용됨.
leader-elector container는 사이드카 형식으로 사용되어
pod에 leader-elector container와 서비스 container 2개를 배포해서 동작함.
pod 내부의 모든 컨테이너는 동일한 네트워크 네임스페이스를 공유하므로 서비스 검색이 필요하지 않음으로
leader-elector container의 http://localhost:4040에 액세스할 수 있음.
리더 선출 프로세스
리더로 선출된 container는 주기적으로 timestamp를 업데이트해서
그룹에 포함된 리더가 아닌 다른 container로 timestamp 정보를 전달함.
리더가 주어진 간격 내에 timestamp를 업데이트하지 못하면 리더에 문제가 있다고 판단하고
리더가 아닌 container가 자신이 리더가 되기 위해 시작함.
kubernetes의 leases.coordination.k8s.io 리소스를 사용해서 동작함.
kubernetes leases란?
Kubernetes leases는 Coordination API 그룹에 속하는 리소스로,
특정 Pod에 대한 리더 선출을 수행하려는 경우 해당 Pod의 이름을 지정하여 leases 리소스를 생성할 수 있음.
leases 리소스는 lease holder와 lease renewer로 구성되어 있음
-
lease holder : 현재 리더 Pod,
-
lease renewer : 새로 선출된 리더 Pod
kubernetes에서 leader-elector 사용법
nginx pod를 배포하고 리더를 선출해봄
예제 yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: iksoon-leader
labels:
app: iksoon-leader-test
spec:
replicas: 3
selector:
matchLabels:
app: iksoon-pod-leader
template:
metadata:
labels:
app: iksoon-pod-leader
spec:
containers:
- name: leader-elector
args:
- --election=example
- --election-namespace=default
- --use-cluster-credentials
- --http=0.0.0.0:4040
image: gleez/leader-elector:0.9
imagePullPolicy: IfNotPresent
- name: iksoon-nginx
image: nginx:1.19.6
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: iksoon-nginx-service
spec:
ports:
- port: 8081
targetPort: 80
selector:
app: iksoon-pod-nginx결과
아래와 같은 3개의 pod가 배포됨
동시에 leases도 배포되어있음.
lease 정보를 확인해보면 현재 iksoon-leader-54f5bd65c9-rgg4q pod가 리더임을 알 수 있음
3개의 pod 중 누가 리더인지 확인
pod/iksoon-leader-54f5bd65c9-bx7xm log를 확인해보니
pod/iksoon-leader-54f5bd65c9-rgg4q 가 리더라고 인식하고 있음
마찬가지로 pod/iksoon-leader-54f5bd65c9-rgg4q 가 리더라고 인식하고 있음
리더인 pod/iksoon-leader-54f5bd65c9-rgg4q 확인해보면
주기적으로 timestamp를 남기며 본인의 상태를 slave container로 전달하고 있음.
leader-elector는 어떻게 사용하는걸까?
위 예제에서 pod에 leader-elector, nginx를 배포했음.
leader-elector를 알기전에 동작을 예상햇던 건
리더 pod가 설정되면 동일한 pod 내부에 있는 nginx가 비활성화 되거나 network 연결을 차단해서
리더로만 통신이 되는줄 알았지만
생각했던 동작과는 거리가 멀었음...
leader-elector와 nginx container는 동일한 network namespace를 사용하고 있어서
nginx에서 leader-elector container로 localhost 통신이 가능함.
테스트에 사용된 nginx와 같은 서비스 container들은
leader-elector container에 request를 보내서
우리가 지금 리더인지 확인을 함.
그리고 리더라면 서비스 container들이 동작하는 로직을 가지고 있음.
즉
서비스 container 자체에서 leader-elector로 request를 보내서 리더임을 확인하는 로직이 필요함.
leader-elector 의 다른 사용법
내용을 참고해보면
서비스 Container가 leader-elector container에 request를 보내서 리더인지 확인할 필요없이
readinessProbe 를 사용해서 동작할 수 있음
하지만...
아래와 같은 이유로 kubernetes가 아닌 container로 leader-elector 실행을 하지 못함.
kubernetes가 아닌 일반 container로 leader-elector 사용법
일반 container도 pod와 같이
network namespace를 공유하는 방법으로
leader-elector container 를 먼저 실행하고
service container를 leader-elector container의 network namespace에 포함해서 동작 시킬 수 있음.
하지만... 아래와 같은 2가지 문제가 있어서 정상 실행이 안됨
-
containerd(nerdctl)에는 readinessProbe를 대체할 기능이 없음.
-
leader-elector는 kubernetes의 leases object를 기반으로 동작함 이를 변경할 수 없음.
leader-elector 코드 참고
리서치 결론
모니터링의 kube-state-metrics 를 leader-elector와 연동하여
Master, Slave를 구성해볼려고 했지만
kube-state-metrics와 leader-elector는 서로 연동이 불가능함으로 사용할 수 없음...
참고
반응형
'Kubernetes > Kubernetes 이론' 카테고리의 다른 글
| kubernetes node name max length가 52인 이유 (0) | 2024.07.14 |
|---|---|
| Kubernetse Linux Namespace 분석 : Pod Container 공유자원 리서치 (0) | 2024.07.14 |
| kubectl cp 명령 특징 (0) | 2022.07.05 |
| 실행 중인 container에 mount하는 방법 (0) | 2022.07.05 |
| Container 관련 기술 리서치 (2) | 2022.03.06 |