Kubernetes - 외부노출방법 2부 본문
apiVersion: apps/v1
kind: Deployment
metadata:
name: deploy-nginx
labels:
app: deploy-nginx
spec:
replicas: 3
selector:
matchLabels:
app: deploy-nginx
template:
metadata:
labels:
app: deploy-nginx
spec:
containers:
- name: nginx
image: nginx
---
apiVersion: v1
kind: Service
metadata:
name: cl-nginx
spec:
selector:
app: deploy-nginx
ports:
- name: http
port: 80
targetPort: 80
type: ClusterIP
ClusterIP와 headless에 대해 알아본다.
얘는 내부 파드들을 연결하는 서비스이다.
클러스터 내부에서 쓰기 위한 목적이다.
ClusterIP와 Headless의 차이점은
apiVersion: v1
kind: Service
metadata:
name: hdl-nginx
spec:
selector:
app: deploy-nginx
ports:
- name: http
port: 80
targetPort: 80
clusterIP: None
headless는 clusterIP 옵션이 None이다.
둘 다 배포를 해본다.
헤드레스는 내부에서 아이피를 소진하지 않고 도메인으로 통신을 한다.
도메인으로 이름이 제공된다면 그 도메인으로 스테이스풀셋을 연결할 수 있다.
즉 헤드레스와 스테이트풀셋의 시너지 효과가 좋다.
여러 테스트를 진행해본다.
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: sts-chk-hn
spec:
replicas: 3
serviceName: sts-svc-domain #statefulset need it
selector:
matchLabels:
app: sts
template:
metadata:
labels:
app: sts
spec:
containers:
- name: chk-hn
image: sysnet4admin/chk-hn
---
apiVersion: v1
kind: Service
metadata:
name: sts-svc-domain
spec:
selector:
app: sts
ports:
- port: 80
clusterIP: None
서비스 배포
배포 후 net을 통해 클러스터 접속 후 nslookup 명령어를 하면 IP가 나온다.
서비스의 이름이 스테이트 풀셋과 다르면 어떻게 될까??
nslookup 쿼리가 안된다.
스테이트 풀셋이 꼭 헤드레스만 되는 것은 아니다.
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: sts-chk-hn
spec:
replicas: 3
serviceName: sts-svc-domain #statefulset need it
selector:
matchLabels:
app: sts
template:
metadata:
labels:
app: sts
spec:
containers:
- name: chk-hn
image: sysnet4admin/chk-hn
---
apiVersion: v1
kind: Service
metadata:
name: sts-svc
spec:
selector:
app: sts
ports:
- port: 80
type: LoadBalancer
다음 예제와 같이 LoadBalancer로도 서비스가 가능하다.
external-ip를 확인하여 접속
이름이 출력된다.
이제 endpoint에 대해 알아본다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: deploy-chk-ip
labels:
app: deploy-chk-ip
spec:
replicas: 3
selector:
matchLabels:
app: deploy-chk-ip
template:
metadata:
labels:
app: deploy-chk-ip
spec:
containers:
- name: chk-ip
image: sysnet4admin/chk-ip
---
apiVersion: v1
kind: Service
metadata:
name: lb-chk-ip
spec:
selector:
app: deploy-chk-ip
ports:
- name: http
port: 80
targetPort: 80
type: LoadBalancer
로드밸런서 svc인데
앤드포인트를 확인해 주자
replicas를 3으로 설정해 두어서 3개가 배포되어 ip 또한 3개이다.
svc의 external-ip로 접속을 해서 확인해 준다.
앤드포인트의 ip를 출력해 주는 애플리케이션이다.
우리가 도달한 앤드포인트는 172.16.103.136
워커노드 2번의 chk-ip 엔드포인트이다.
이게 임의로도 엔드포인트를 만들 수 있다.
apiVersion: v1
kind: Service
metadata:
name: external-data
spec:
ports:
- name: http
port: 80
targetPort: 80
---
apiVersion: v1
kind: Endpoints
metadata:
name: external-data
subsets:
- addresses:
- ip: 192.168.1.11
ports:
- name: http
port: 80
진행 중이던 lb-chk-ip의 external-ip와 동일시해준다.
앤드포인트 172.16.221.135로 연결되었다.
약간 더블 바인딩 느낌??이라고 생각한다.
마지막 Ingress에 대해 알아본다.
엔드포인트에서 확장된 기능이고.
쿠버네티스의 철학?? 신념? 과 매우 유사하다.
먼저 yaml파일 3개 배포해 줄 것이다.
첫 번째
apiVersion: apps/v1
kind: Deployment
metadata:
name: deploy-nginx
labels:
app: deploy-nginx
spec:
replicas: 3
selector:
matchLabels:
app: deploy-nginx
template:
metadata:
labels:
app: deploy-nginx
spec:
containers:
- name: nginx
image: nginx
---
apiVersion: v1
kind: Service
metadata:
name: ing-default
spec:
selector:
app: deploy-nginx
ports:
- name: http
port: 80
targetPort: 80
type: ClusterIP
두 번째
apiVersion: apps/v1
kind: Deployment
metadata:
name: deploy-hn
labels:
app: deploy-hn
spec:
replicas: 3
selector:
matchLabels:
app: deploy-hn
template:
metadata:
labels:
app: deploy-hn
spec:
containers:
- name: chk-hn
image: sysnet4admin/chk-hn
---
apiVersion: v1
kind: Service
metadata:
name: ing-hn
spec:
selector:
app: deploy-hn
ports:
- name: http
port: 80
targetPort: 80
type: ClusterIP
세 번째
apiVersion: apps/v1
kind: Deployment
metadata:
name: deploy-ip
labels:
app: deploy-ip
spec:
replicas: 3
selector:
matchLabels:
app: deploy-ip
template:
metadata:
labels:
app: deploy-ip
spec:
containers:
- name: chk-ip
image: sysnet4admin/chk-ip
---
apiVersion: v1
kind: Service
metadata:
name: ing-ip
spec:
selector:
app: deploy-ip
ports:
- name: http
port: 80
targetPort: 80
type: ClusterIP
3개의 파일 모두 동일한 맥락이다.
3개의 서비스를 모두 배포해 준다.
이제
인그레스에 대해 뜯어본다.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: nginx-ingress
annotations:
kubernetes.io/ingress.class: "nginx"
spec:
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: ing-default
port:
number: 80
- path: /hn
pathType: Prefix
backend:
service:
name: ing-hn
port:
number: 80
- path: /ip
pathType: Prefix
backend:
service:
name: ing-ip
port:
number: 80
annotations가 어디를 주체로 매핑할 것인지이다.
나는 nginx를 주체로 매핑한다.
그다음 인그레스는 컨트롤러가 필수적으로 필요하다.
리소스만으로는 사용할 수 가없다.
쿠버네티스가 지원하는 인그레스 컨트롤러는 AWS, GCE, Nginx 인그레스 컨트롤러가 있다.
나는 Nginx 인그레스 컨트롤러를 사용한다.
인그레스 리소스를 배포하고
nginx 인그레스 컨트롤러도 배포해 준다.
그리고 서비스를 확인해 준다.
노드포트 형식이기에 노드 ip로 접속
이제 결과를 보면
인그레스가 뭐 하는 애인지 단번에 파악 가능하다.
노드포트뿐만 아니라
로드밸런서 서비스로도 가능하다.
기존의 노드포트 서비스를 지우고 실습해 본다.
external-ip 접속하면 아까 노드포트로 접속한 거랑 똑같은 화면을 볼 수 있다.
'Kubernetes' 카테고리의 다른 글
Kubernetes - 볼륨 2부 (0) | 2023.12.26 |
---|---|
Kubernetes - 볼륨 1부 (1) | 2023.12.21 |
Kubernetes - 외부노출방법 1부 (0) | 2023.12.11 |
Kubernetes - 배포 종류 (1) | 2023.12.09 |
kubernetes - 명령어 (0) | 2023.12.06 |