쿠버강의 hands-on _ 5

 

 

 

 

 

 

 

service 

 

애플리케이션 안팎의 다양한 구성 요소간의 통신을 가능하게 함

=> 애플리케이션 - 애플이케이션 / 유저 연결에 도움을 줌 

 

 

 

 

usecase

 

외부에서 웹으로 접근하려고 할때

==> 이 경우는 노드안에서  직접 접근한것 임

=> 이런방식은 좋지 않음

 

 

 

 

 

 

 

node port service

=> 서비스가 노드의 port에 요청이 들어오면 => pod로 요청해줌 

 

=> 이런식으로 동작함 

 

 

 

 

 

 

 

 

클러스터 ip

=> 클러스터 안에 가상의 ip를 만들어서 다양한 서비스간에 통신을 하게 해주는것

 

 

service - node port 

 

 

노드의 port와 pod의 port를 연결해주는 서비스

 

서비스 => 사실상 노드 내부의 가상서버 => 클러스터 내부의 가상 서버 

 

 

 

 

=> 

클러스터 ip / nodeport / 로드밸런서  가 될 수 있음

 

=> 노드 포트를 지정하지 않으면, 할당 범위내에서 자동으로 할당됨

===> ++ 라벨과 selector를 이용해서 service와 pod를 연결

 

 

=> 확인하면 cluster-ip와 지정해준 포트들을 볼 수 있음

 

 

 

 

다중 웹 서버일 경우에도 label을 같게 지정해두면

=> service가 알아서 이것들을 추적해서 연결하기 때문에, 이 부분에 대해서 추가적인 구성이 필요하지는 않음

 

 

 

 

다중 노드 애플리케이션

 

 

=> 다중 노드일 때도 문제없이, 어떠한 cluster ip = 노드 ip를 사용하여 접근하게 되도 노드 안에 있는 애플리케이션에 접근할 수 있도록 해놓음

=>  노드의 개수에 상관없이 서비스는 모든 노드를 아우를 수 있게 생성됨

===> pod의 추가 / 제거에 따라서 자동으로 업데이트됨

===> pod의 개수 자체는 같은 개수로 유지된다고 하더라도, 장애 / 업데이트 등등의 이유로 pod 자체는 계속 변할 수 있음

 

 

 

 

demo

apiVersion: apps/v1

kind: Deployment

metadata:

  name: myapp-deployment

  labels:

    tier: frontend

    app: nginx

    

spec:

  replicas: 6

  selector:

    matchLabels:

      app: myapp

  template:

    metadata:

      name: nginx-2

      labels:

        app: myapp

 

    spec:

      containers:

        - name: nginx

          image: nginx

 

 

선생님의 실습환경이랑 비슷하게 만들어봄

=> 배포파일을 만들어서 배포 

 

+ 

 

=> 서비스를 생성

 

 

service = svc

 

=> 내부에서 접근하기위한 클러스터 ip

 

=>이제 노드 ip + 30004 => 접근 가능하게 되는것임

=> 실제 환경이라면(ex - minikube) => 이걸 통해서 

 

minikube service myapp-service --url => url 도출

 

=> 실제 웹 환경(브라우저)으로 가서 저 url로 접근하면 => 노드 내에 있는 서비스에 접근이 가능한것임

 

 

 

 

cluster ip

 

 위에서 간단하게 언급한것 처럼, pod는 계속 교체되고 / 만들어지기 때문에 pod ip에 의존해서 서비스를 할 수 없음

=> 따라서 cluster ip를 사용하는 것임

 

=> 여러 서비스에 접근할 수 있는 하나의 인터페이스를 만들어놓고 => 이쪽으로 접근하면, 무작위의 한 포드에 전달되는 형태 

 

=> 이것도 똑같이 .yaml파일을 사용함

 

type ClusterIP   ==> default 

=> 아무것도 지정해놓지 않으면 자동으로 ClusterIP의 형식으로 만들어짐 

 

 

apiVersion: v1

kind: Service

metadata:

  name: back-end

spec:

  type: ClusterIP

  ports:

    - port: 80

      targetPort: 80

 

  selector:

    app: myapp

    type: back-end

 

 

 

=> 스크립트 => IP는 대문자로 써야함

 

 

 

 

 

 

 

loadbalancer 

apiVersion: v1

kind: Service

metadata:

  name: image-processing

  labels:

    app: myapp

 

spec:

  type: ClusterIP

  ports:

    - targetPort: 80

      nodePort: 8080

  selector:

    tier: backend

 

 

 

deployment.yaml  => 이걸 참고해서 적었어야했음

 

apiVersion: apps/v1

kind: Deployment

metadata:

  name: image-processing-deployment

  labels:

    tier: backend

spec:

  replicas: 4

  template:

    metadata:

      name: image-processing-pod

      labels:

        tier: backend

    spec:

      containers:

        - name: mycustom-image-processing

          image: someorg/mycustom-image-processing

  selector:

    matchLabels:

      tier: backend

 

 

=> 쭉~~ 작성하는 부분에서 처음 작성한것

 

 

답

 

 

apiVersion: v1

kind: Service

metadata:

  name: image-processing

  labels:

    app: myapp

spec:

  # type: ClusterIP

  ports:

    - port: 80

      targetPort: 8080

  selector:

    tier: backend

 

 

=> 이해를 잘 못했네 => image-processing이 이름이고 이 컨테이너에서 열려있는 포트면 당연히 서비스에 붙어있는 포트를 말한건데 => 이건 targetport이고 

 

=> 그래도 그것만 틀렸네

 

 

 

 

 

 

hands-on

 

controlplane ~ ➜  k get svc

NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE

kubernetes   ClusterIP   10.43.0.1    <none>        443/TCP   7m9s

 

=> 처음들어갔을 때 있는 서비스는 기본적으로 쿠버에서 실행시킨 서비스임 

 

 

 

 

=> 이미지도 이걸로 볼 수 있고 

==> 생각보다 k get  ~     -o wide로 얻을 수 있는 정보가 많았음 => 종류에 따라서 나오는 정보도 다름 => 잘 골라서 사용하면 될듯함

 

 

=> 관련 사용법에 대해서는 여러 블로그에서 찾아볼 수 있듯이 공식 문서에서 찾아보는 습관을 길러야함 => 북마크쓰는것도 익숙해지고 

 

 

 

 

 

 

microservice application

 

 

redis => inmemory db

mariadb => 영구적

 

간단한 앱의 데이터 흐름

 

 

이걸 이제 도커에서 돌려볼 것임 

 

 

=> db단을 설정해주고 

 

 

=> 애플리케이션과 작업 노드를 설정 

==> 아직 앱과, db, 등등을 서로 연결해주지 않았기 때문에, 제대로된 접근을 할 수가 없음

 

vote-app => redis쓰라고 말하지 않았고

result-app => db쓰라고 말하지 않았음

 

--links => cli option => 컨테이너에 함께 링크하는데 사용됨

 

 

 

 

 

vote-app => 지금 만든 redis를 사용할꺼라고 지정

result-app => 지금 만든 db를 사용해줄꺼라고 지정

 

=> 작업 노드에는 두개를 다 지정해 주었음

 

=> 이런 방식이 나중에는 지원되지 않을 수 있음

=> docker swarm과 네트워킹을 통해서 더 나은 결과물을 도출할 수 있기 때문에 

 

===>  // 도커로 만드는법

 

 

쿠버에 배포하는 법 

 

=> 우선 쿠버에 올리기 전에 어떤 목표를 가지고 배포할 것인가를 먼저 정해야함

 

 

 

1. 각 서비스를 pod에 배포

 

 

 

 

2. 각 서비스를 연결 

=> 어떤 프로그램  / 어떤 서비스 /  어떤 액세스를 요구하는지를 확실히 명시 / 가지고 있어야함

 

 

 

-> 작업노드로 들어가는 접근이 없기 때문에, 관련 권한을 줄 필요가 없음

==> 관련 서비스가 없음(타인에게 노출되어야할때만 필요함)

=> 타인이 액세스 가능해야할 경우에

 

 

-> 각 정보를 저장하는 redis / db는 작업노드와 각자의 앱에서 접근을 해야함

 

 

 

==> 그럼 앱이 db에 어떻게 접근을 해야할까 ?

==> db의 pod ip?  => pod의 ip가 언제 바뀔줄도 모르고 / 해당 pod가 언제 다른 pod로 바뀔지도 모름 => 이런 방법은 안됨

 

===> service를 이용한 방법이 좋음(db가 들어있는 pod로 직접 접근하지 않기 때문에)

 

 

 

=> 서비스를 이용해서 클러스터 내에서 어디서든 접근이 가능하게 만들어주고 

 

 

 

=> 외부에서의 접근이 가능하게 만들어줬음 

 

 

 

 

=> 각각 파드가 이렇게 지정될 것임

 

demo

 

관련 파일들을 쭉 따라 만들어봤음 -> 아직 환경이 구축되어있지 않아서 이걸 그대로 할 수는 없지만, 나중에 미니쿠베라도 환경설정이 끝나면 한번 실행해봐야겠다 

 

 

postgres-pod.yaml

 

apiVersion: v1

kind: Pod

metadata:

  name: postgres-pod

  labels:

    name: postgres-pod

    app: demo-voting-app

spec:

  containers:

    - name: postgres

      image: postgres

      ports:

        - containerPort: 5432

      env:

        - name: POSTGRES_USER

          value: "postgres"

        - name:  POSTGRES_PASSWORD

          value: "postgres"

  

==> 

기초 과정이라 자격증명을 하드코딩했지만(코드에 담에서 배포) 원래대로라면 이렇게 하면 안됨 => 보안상으로 좋지 않기 때문에

-> aws같은 경우로  생각하면 secret manager나 parameter store를 이용해야함