[쿠버네티스 인 액션] 5장.서비스 - 레디니스 프로브, 헤드리스 서비스, 서비스 해결
5.6 레디니스 프로브
- 주기적으로 호출되며 특정 파드가 클라이언트 요청을 수신할 수 있는지를 결정한다.
- 컨테이너의 레디니스 프로브가 성공을 반환하면 컨테이너가 요청을 수락할 준비가 됐다는 신호다.
- 3가지 유형의 레디니스 프로브가 있다.
1) exec 프로브는 컨테이너의 상태를 프로세스의 종료 상태로 결정
2) get 프로브는 get 요청을 컨테이너로 보내고 결정
3) tcp 소켓 프로브는 지정된 포트로 tcp 연결 후 연결되면 준비된 것으로 간주
kubernetes-in-action/Chapter05/kubia-rc-readinessprobe.yaml at master · luksa/kubernetes-in-action
Code from the Kubernetes in Action book. Contribute to luksa/kubernetes-in-action development by creating an account on GitHub.
github.com
apiVersion: v1
kind: ReplicationController
metadata:
name: kubia
spec:
replicas: 3
selector:
app: kubia
template:
metadata:
labels:
app: kubia
spec:
containers:
- name: kubia
image: luksa/kubia
ports:
- name: http
containerPort: 8080
readinessProbe:
exec:
command:
- ls
- /var/ready
레디니스 프로브는 컨테이너 내부에서 ls /var/ready 명령어 주기적으로 수행하며 파일이 존재하면 종료 코드 0을, 그렇지 않으면 0이 아닌 값을 반환.
- 주의해야할 점
> 파드에 레디니스 프로브를 반드시 추가할것. 추가하지 않으면 시작하는 즉시 서비스 앤드포인드가 되면서 connection refused 유형의 에러가 난다.
> 파드의 종료코드 포함하지 말것. 파드가 종료할 때, 연결 수락을 중단하기 때문에 종료 절차가 시작되는 즉시 레디니스 프로브가 실행하도록 되어야 한다고 생각하지만, 쿠버네티스는 파드를 삭제하자마자 모든 서비스에서 파드를 제거하기 때문에 필요하지 않다.
5.7 헤드리스 서비스
apiVersion: v1
kind: Service
metadata:
name: kubia-headless
spec:
clusterIP: None
ports:
- port: 80
targetPort: 8080
selector:
app: kubia
5.8 서비스 해결
- 첫 번째로 외부가 아닌 클러스터 안에서 클러스터 IP를 대상으로 연결하고 있다는 것을 명심하라.
- 서비스가 액세스 가능한지 확인하기 위해 서비스 IP로 핑을 보내는 것을 귀찮게 여기지 마라(기억해라, 서비스의 클러스터 IP는 가상 IP이고 핑을 보내도 응답이 없을 것 이다).
- 레디네스 프로브를 정의했다면 성공 여부를 확실히 확인하라. 그렇지 않으면 포드 는 서비스의 일부로서 동작하지 않는다.
- 포드가 서비스의 일부분인지 확인하려면 kubectl get endpoints 명령으로 그에 상 응하는 엔드포인트를 조사하라.
- FQDN이나 그것의 일부로서(예를 들면, myservtce.mynamespace.svc.cluster.local 또는 myservice.mynamespace) 서비스에 액세스를 시도하고 있으나 정상 동작하지 않고 있 다. FQDN 대신에 클러스터 IP를 통해 액세스하고 있는지 확인하라.
- 대상 포트가 아닌 서비스에 의해 노출된 포트에 연결하고 있는지를 확인하라.
- 포드IP에 직접 연결을 시도해 포드가 정확한 포트의 연결을 수락하고 있는지 확인하라.
- 포드의 IP로도 애플리케이션에 직접 액세스할 수 없다면 애플리케이션이 localhost에만 바인드하고 있지는 않은지 확실히 확인하라.