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 접속하면 아까 노드포트로 접속한 거랑 똑같은 화면을 볼 수 있다.