본문 바로가기
Docker

Kubenetes(2)

by 황밤 2023. 10. 13.
728x90
반응형

2023/10/13

Kubenetes

 

 

1. 초기화

  • minikube
    • 서비스 중지 : minikube stop
    • 인스턴스 삭제 : minikube delete
    • 프로필 삭제 : minikube delete --all
    • 서비스 다시 시작 : minikube start
  • Docker Desktop의 쿠버네티스
    • 쿠버네티스 설정 메뉴에서 reset kubenets cluster를 클릭

2. Daemon Set

2.1) 개요

  • 모든 노드에 파드를 생성하고자 할 때 사용
  • Replica Set 은 특정 개수의 파드를 생성할 때 사용하고 Daemon Set은 모든 노드에 생성
  • 모니터링 용도로 주로 사용 - 로깅하는 프로그램을 사용할 때 활용
  • 클라우드 환경에서 모니터링 용도로 가장 많이 사용되는 애플리케이션은 프로메테우스 입니다. 
    • 시각화는 그라파나를 이용하는 경우가 많은데, 다른 시각화 도구를 사용해도 가능

2.1) 실습

  • Daemon Set을 생성하기 위한 매니페스트 파일을 생성 - daemonsets.yaml 파일
apiVersion: apps/v1

kind: DaemonSet #배포할 오브젝트 종류 설정

#메타 데이터 설정 - 기본이 되는 옵션
metadata:
  name: prometheus-daemonset #디플로이먼트 이름
  

spec:
  selector:
    matchLabels:
      tier: monitoring #모니터링 용도로 사용할 것이라고 알려주기 위해서 레이블 생성
      name: prometheus-monitor
  #실제 파드를 만들 정보
  template:
    metadata:
      labels:
        tier: monitoring #모니터링 용도로 사용할 것이라고 알려주기 위해서 레이블 생성
        name: prometheus-monitor      
    
    #컨테이너 정보를 설정
    spec:
      containers:
      - name: prometheus
        image: prom.node-exporter
        ports:
        - containerPort: 80
  • 파드 생성 : kubectl apply -f daemonsets.yaml
  • 파드 확인 : kubectl get pods
  • 자세히 보기 : kubectl describe 오브젝트 종류/디플로이먼트 이름
    • kubectl describe daemonset/prometheous-daemonset
  • 삭제 
    • 이 경우는 데몬 셋을 이용해서 파드를 생성
    • 데몬셋을 삭제하면 파드가 자동으로 삭제 됩니다.
    • kubectl delete -f daemonsets.yaml

3. cron job

3.1) 쿠버네티스 작업의 종류

  • Run-to-Completion : 컨테이너에 동작을 명시해서 수행하는 작업
  • CronJob : 일정한 주기를 가지고 작업을 수행
    • Action: 특정한 작업이 수행되었을 때 동작 - 트리거가 특정한 작업임.
    • Cron: 주기를 가지고 동작 - 트리거가 주기(기간)임

3.2) Cron Job

  • 일정한 주기를 가지는 데이터 수집, 애플리케이션 수행, 데이터 백업 등

3.3) CronJob을 만들 때 spec에 schedule을 설정

  • schedule: 분(0-59) 시(0-23) 일(0-31) 월(1-12) 요일(0-6)     #요일은 0이 일요일
  • 분 단위 생성 : */1(1분 단위)
  • 배열은 ,로 구분해서 설정

3.4) 작업 설정

  • command 를 이용해서 설정

3.5) kind는 CronJob

 

3.6) 크론잡을 만들면 하나의 파드가 생성되고 작업을 하고 완료되는 것을 반복합니다.

 

3.7) 실습

  • 크론잡 생성을 위한 매니페스트 파일을 생성 - cronjobs.yaml(yml, eyaml)
  • 크론잡 배포 : kubectl create -f 파일경로
  • 크론잡을 확인 : kubectl get cronjob 크론잡이름
  • 파드의 동작을 확인 (크론잡은 파드를 생성하고 패기하는 작업을 반복): kubectl get pods
  • 크론잡 삭제 : kubectl delete cronjob 크론잡이름
apiVersion: batch/v1

kind: CronJob #생성하고자 하는 오브젝트 종료

#메타 데이터 설정 - 기본이 되는 옵션
metadata:
  name: hello #cronjob 이름
  

spec:
  schedule: "*/1 * * * *"  #1분 마다 수행 - 스케쥴 지정
  jobTemplate:
    spec:
      template:
        spec: 
          containers:
          - name: hello
            image: busybox #리눅스만 설치된 이미지
            imagePullPolicy: IfNotPresent #이미지가 없을 때에만 내려받음
            command: 
            - /bin/bash
            - -c
            - date; echo Hello from the Kubenetes Cluster

 

4. CoreDNS

 

4.1) DNS(Domain NAme Service)

  • Domain 과 IP 주소를 변환해주는 서비스
  • 브라우저에 입력할 때는 https//www.kakao.com 이라고 입력을 하지만 컴퓨터의 주소는 숫자로 되어있다.
  • 따라서 이를 211.249.211.105 로 변환을 해주어야 하는데 이를 수행하는 것이 DNS

4.2) Core DNS

  • 쿠버네티스가 가지고 있는 DNS
  • 클러스터를 지속적으로 모니터링해서 정보를 업데이트
kuberctl 이라는 명령 체제
kubernetes - cli 를 다운로드

전체 클러스터 중,
개발자는 kuberctl을 이용해 Master를 컨트롤 하고 나머지 Worker를 관리

API Server를 사용해 etcd라는 DB에 scheduler를 이용해 작업 (사용량 등을 주기적으로 관리)

API가 Worker Node 에 pod를 생성, pod 속 container가 작업을 수행

-> 외부에서 접속하려면 해당container node의 IP와 접속 port를 전부 알아야함
CoreDNS 를 이용하면  Kubenetes에서 DNS 역할을 수행해 접속을 가능하게 해줌.
  • 대표적인 UDP 서비스 중 하나 

 

5. Config Map 과 Secret

5.1) 환경 변수

  • 내부에서는 고정적으로 사용이 되지만 상황에 따라 다르게 설정되는 데이터를 별도로 저장해 두는 것
  • 리눅스에서는 환경변수를 가져와서 사용할 때 $환경변수 또는 $(환경변수) 의 형태로 입력합니다.
  • 원래 환경변수가 중요한 곳은 프로그래밍입니다.
    • 내부에서는 고정적으로 사용이 되지만 상황에 따라 다르게 설정되는 데이터를 하드 코딩(소스 코드에 작성)하게 되면 값을 변경해야 할 때 컴파일과 빌드를 다시 해야하는 번거로움이 있음.
    • 프로그래밍에서는 저런 데이터를 별도의 텍스트 형태의 파일(properties-env, xml, json, yaml 등)이나 데이터베이스에 저장해두고 사용하는 것을 권장합니다.

5.2) yaml 파일 내부에 생성

  • env 키를 이용해서 name 과 value를 설정하고 사용을 할 때는 $(name) 의 형태로 사용 가능
spec:
  - name:
  
  ...
  
  env: 
  - name: GREETING
    value: "Hello"
    
  ...
  command: ["echo"]
  args: [$(GREETING)] #이 자리에 "Hello" 가 입력되게 됨.
  • 여러 번 사용하지 않는다면 굳이 할 이유가 없음.

5.3) 별도의 파일에 작성 - Config Map

  • 명령
    • kubectl create configmap < 맵 이름> <파일 경로> <인자>
    • 인자에는 --from-file, --from-env-file, --from-literal
    • --from-file 과 --from-env-file 은 둘 다 외부 파일을 이용해서 설정하는데 --from-file 은 내용 전체가 하나의 이름으로 묶이는 것이고, --from -env-file은 Key, Value 형태로 내용을 작성해서 여러 개의 값을 가질 수 있습니다.
    • --from-literal 은 직접 key 와 value를 작성
  • literal을 이용
    • 변수 생성
      • kubectl create configmap my-config --from-literal=JAVA_HOME=/usr/java
      • kubectl create configmap my-config --from-literal=JAVA_HOME=/usr/java --from-literal=URL=https://www.oracle.com (여러개 작성시)
    • 확인
      • kubectl get configmap
      • kubectl describe configmap/my-config
    • 파일 이용
      • 파일 작성 : env.txt
HOMETOWN=크라이스처리
JOB=학생
AGE: 13
  • kubectl create configmap my-env --from-file=env.txt

차이점

 

5.4) secret

  • 민감한 정보를 저장하는 용도로 사용
  • 컨테이너에 저장하지 않고 별도로 보관해두었다가 실제 파드가 실행될 때 시크릿 값을 가져와서 파드에 제공
  • 사용법은 configmap 과 거의 유사
  • 생성
    • kubectl create secret generic 시크릿이름 파일경로 옵션
    • kubectl create secret generic db-user-pass --from-literal=username=itbam --from-literal=password=svng
  • 확인
    • kubectl get secret
  • 화면에 보여지는 문자열
    • kubectl get secret db-user-pass -o jsonpath='{.data}'
      '{"password":"c3ZuZw==","username":"aXRiYW0="}'

      원래 값을 알아낼려면 base64 디코딩을 해야 합니다.

6. 볼륨

6.1) 개요

  • 볼륨은 데이터를 저장하는 저장소
  • 파드는 휘발성
    • 파드에 데이터를 저장한 후 디플로이먼트가 파드를 재시작하게 되면 저장된 데이터는 모두 소멸됩니다.

 

  • 파드의 데이터가 없어지지 않도록 하는 것이 볼륨

6.2) 종류

  • 파드 내에 위치 : 파드가 종료될 때 소멸
    • emptyDir 이라고 합니다.
  • 워크 노드에 위치 : 파드가 종료되어도 데이터는 유지가 되지만 워커 노드가 종료되면 소멸
    • hostPath 라고 합니다.
  • 노드 외부에 위치 : 데이터는 항상 보존
    • 클라우드의 서비스를 이용하는 경우가 많습니다.
    • NFS, cephFS, glusterFS, iSCSI, AWS EBS, azureDisk

6.3) emptyDir 사용

  • 파드 내에 만든 데이터 저장소
  • 일시적으로 보관하기 위한 데이터를 저장
  • 컨테이너 내에 파일등을 만들어서 보관하고자 하는 경우 사용 가능
  • spec 안에 volumes 를 이용해서 이름을 설정하고 값으로 emptyDir: { } 를 설정하면 됩니다.
    • 실제 디렉토리에 마운트시켜 사용

6.4) emptyDir 실습 - 디렉토리가 생성되는지 확인

  • pod 를 만들기 위한 매니페스트를 생성 - emptydir.yaml
apiVersion: v1
kind: Pod
metadata:
  name: emptydir
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: shared-storage
      mountPath: /data/shared
  volumes:
  - name: shared_storage
    emptyDir: {} #파드 내에 저장소를 생성

 

  • 파드 생성
    • kubectl apply -f emptydir.yaml
  • 파드 생성
    • kubectl exec -it emptydir -- /bin/bash
  • 디렉토리 생성 여부 확인
    • cd /data/shared
  • 데이터 저장 방법
root@emptydir:/data/shared# echo "kubenetes" >> test.txt
root@emptydir:/data/shared# ls
test.txt
root@emptydir:/data/shared# open text.txt
bash: open: command not found
root@emptydir:/data/shared#
root@emptydir:/data/shared# cat test.txt

 

 

  • 파드가 소멸되면 데이터가 없어지는 것을 확인
C:\Users\USER\kubenetes>kubectl delete pod emptydir
Error from server (NotFound): pods "emptydir" not found

C:\Users\USER\kubenetes>kubectl apply -f emptydir.yaml
pod/emptydir created

C:\Users\USER\kubenetes>kubectl exec -it emptydir -- /bin/bash
root@emptydir:/# cd /data/shared
root@emptydir:/data/shared# ls
root@emptydir:/data/shared# ls
root@emptydir:/data/shared#

 

6.5) hostPath 이용

  • 워커 노드의 로컬 디스를 파드에 마운트해서 사용하는 볼륨
  • 동일한 hostPath를 사용하는 다수의 파드끼리 데이터를 공유할 수 있는 장점이 있음
  • 파드가 삭제되더라도 hostPath에 데이터가 남아있기 때문에 다른 파드나 새로 생성되는 파드가 그 데이터를 계속 사용하는 것이 가능합니다.
  • volumne을 생성할 때 이름과 hostpath를 설정하고 hostpath에 실제 연결될 디렉토리를 설정해 주저야 합니다.
  • 파드 생성을 위한 매니페스트 파일을 생성 - hostpath.yaml
apiVersion: v1
kind: Pod
metadata:
  name: hostpath
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: localstorage
      mountPath: /data/local
  volumes:
  - name: localstorage
    emptyDir: {} #파드 내에 저장소를 생성

 

  • 파드 생성 및 확인
    • kubectl apply -f hostpath.yaml
    • kubectl get pods
  • 파드에 접속해서 디렉토리가 생성되었는지 확인하고 파일을 작성한 후 파일 생성 여부 확인
    • kubectl exec -it hostpath -- /bin/bash
    • date > sample.txt
    • ls -a >> sample
    • ls
    • cat sample.txt
  • 파드를 삭제
    • kubectl delete pod/hostpath
  • 다시 파드를 생성
    • kubectl apply -f hostpath.yaml
  • 파드에 접속해서 디렉토리가 생성되었는지 확인하고 파일을 작성한 후 파일 생성 여부 확인
C:\Users\USER\kubenetes>kubectl apply -f hostpath.yaml
pod/hostpath created

C:\Users\USER\kubenetes>kubectl get pods
NAME                         READY   STATUS              RESTARTS       AGE
emptydir                     1/1     Running             0              22m
hello-28286111-tjnfv         0/1     CrashLoopBackOff    5 (2m7s ago)   5m7s
hello-28286112-h987p         0/1     CrashLoopBackOff    5 (70s ago)    4m7s
hello-28286113-bxrs5         0/1     CrashLoopBackOff    4 (94s ago)    3m7s
hello-28286114-qdjn4         0/1     CrashLoopBackOff    4 (46s ago)    2m7s
hello-28286115-t8lxd         0/1     CrashLoopBackOff    3 (34s ago)    67s
hello-28286116-qgbh2         0/1     RunContainerError   0 (7s ago)     7s
hostpath                     1/1     Running             0              5s
prometheus-daemonset-fvwvb   0/1     ImagePullBackOff    0              166m

C:\Users\USER\kubenetes>kubectl exec -it hostpath.yaml -- /bin/bash
Error from server (NotFound): pods "hostpath.yaml" not found

C:\Users\USER\kubenetes>kubectl exec -it hostpath -- /bin/bash
root@hostpath:/# exit
exit

C:\Users\USER\kubenetes>kubectl delete hostpath
error: the server doesn't have a resource type "hostpath"

C:\Users\USER\kubenetes>kubectl delete pod/hostpath
pod "hostpath" deleted

C:\Users\USER\kubenetes>kubectl apply -f hostpath.yaml
pod/hostpath created

C:\Users\USER\kubenetes>kubectl exec -it hostpath -- /bin/bash
root@hostpath:/# hi
bash: hi: command not found
root@hostpath:/# date > sample.txt
root@hostpath:/# ls -a
.           data                  home    media  run         tmp
..          dev                   lib     mnt    sample.txt  usr
.dockerenv  docker-entrypoint.d   lib32   opt    sbin        var
bin         docker-entrypoint.sh  lib64   proc   srv
boot        etc                   libx32  root   sys
root@hostpath:/# ls -a >> sample
root@hostpath:/# ls
bin   dev                   etc   lib32   media  proc  sample      srv  usr
boot  docker-entrypoint.d   home  lib64   mnt    root  sample.txt  sys  var
data  docker-entrypoint.sh  lib   libx32  opt    run   sbin        tmp
root@hostpath:/#
  • 파드가 삭제된 후 다른 워커 노드에 생성되면 이전 데이터에 접근이 안됩니다.

 

6.6) 영구 볼륨과 영구 볼륨 클레임

  • emptyDir 을 사용하면 파드가 삭제되면 데이터가 소멸되고 hostpath를 이용하더라도 워커 노드가 변경되면 소멸됩니다.
  • 디플로이먼트로 생성되는 파드는 휘발성
    실제 운영되는 시스템에서는 파드가 비정상적으로 종료되었더라도 데이터를 유지해 줄 수 있어야 합니다.
  • 영구 볼륨
    컨테이너, 파드, 노드의 종류와 무관하게 데이터를 영구적으로 보관할 수 있는 볼륨
    • 영구 볼륨(Persistent Volume - PV)은 시스템 관리자가 외부 저장소에서 볼륨을 생성한 후 쿠버네티스 클러스터에 연결하는 것을 의미
    • 쿠버네티스 클러스터 <-> 영구 볼륨 <-> 외부 저장소
    • 개발자가 디플로이먼트로 파드를 생성할 때 볼륨을 저장하는데 이 때 볼륨 자체를 정의하는 것이 아니라 볼륨을 요청하는 볼륨 클레임을 지정
      영구 볼륨을 요청하는 볼륨 클레임을 영구 볼륨 클레임(Persistent Volume Claim - PVC)이라고 합니다.

      파드 <-> 영구 볼륨 <-> 외부 저장소
      볼륨 마운트
      volume:
      - Claim Name -> 영구 볼륨 클레임 -> 영구 볼륨을 요청 -> 외부 스토리지

      개발자가 파드를 생성할 때 볼륨을 요청하는 영구 볼륨 클레임을 정의하면 볼륨이 자동으로 할당
      실제로 마운트되는 볼륨이 무엇인지 알 필요가 없음.

      작업을 할 때는 영구 볼륨 설정, 영구 볼륨 클레임, 디플로이먼트, 서비스를 만들어야 합니다.
      데이터 베이스를 이용하는 파드를 만들 때는 이러한 작업을 전부 수행해야 합니다.
      이 작업이 쉽지 않아서 클라우드를 이용하는 경우 이 작업을 생략하는 경우가 많고 이 작업을 해야 한다면 클라우드가 제공하는 데이터베이스(AWS 의 RDS 나 Dynamo DB 등)를 이용하는 경우가 많습니다.
      (이 작업 없이 진행 중, 워커가 죽게 되면 데이터가 사라지게 됨)

 

6.7) 영구 볼륨 사용 실습: mysql 데이터베이스에 영구 볼륨을 마운트

  • 영구 볼륨을 위한 매니페스트 파일을 생성 - 편의상 hostpath 이용 (실제로는 클라우드의 외부 저장소를 사용해야 하는데 현재는 외부 저장소가 없기 때문) : pv.yaml
apiVersion: v1
kind: PersistentVolume #영구 볼륨 생성
metadata: 
  name: mysql-pv-volume
  labels:
    type: local
spec: #무엇인가를 만드는 부분
  storageClassName: manual #영구 볼륨 클레임의 요청을 현재 영구 볼륨에 바인딩
  capacity:
    storage: 10Gi #용량 할당 - 중간에 수정하는 경우가 많음
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data" #나중에 이 부분은 외부 저장소의 URL로 변경을 해야함.(Amazon 의 경우는 EFS 서비스 활용)
  • 매니페스트 파일 적용
    • kubectl apply -f pv.yaml
  • 영구 볼륨 클레임을 위한 매니페스트 생성 : pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim #영구 볼륨 클레임 생성
metadata: 
  name: mysql-pv-claim

spec:
  storageClassName: manual #영구 볼륨 클레임의 요청을 현재 영구 볼륨에 바인딩
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

 

  • 영구 볼륨 클레임 생성
    • kubectl apply -f pvc.yaml
  • mysql 을 배포하기 위한  pvc-deployment.yaml
  • 배포
    • kubectl apply -f pvc-deployment.yaml
  • 외부에서 MySQL로 접속할 수 있도록 해주는 서비스를 위한 매니패스트 파일을 생성 - mysql_service.yaml
apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  clusterIP: None
  ports:
  - port: 3306
  selector: 
    app: mysql
  • 배포
    • kubectl create -f mysql_service.yaml
  • 현재 디플로이먼트 상태 확인
    • kubectl describe deployment mysql
    • Volume과 마운트가 되었는지 확인
  • 현재 파드의 상태 확인
    • kubectl get pods
  • 현재 서비스 상태 확인
    • kubectl get service - service 대신에 svc 로 입력해도 됨
  • 영구 볼륨 확인
    • kubectl get persistentvolume(pv로 줄여도 됩니다.)
    • RECLAIM POLICH: 영구 볼륨의 라이프 사이클 정책으로 영구 볼륨 클레임을 삭제할 때 영구 볼륨과 연결된 저장소의 파일을 어떻게 처리할 지를 선택
      • Retain : 영구 볼륨 클레임을 삭제하더라도 영구 볼륨의 파일은 남겨두는 방식
      • Delete : 영구 볼륨 클레임을 삭제할 때 영구 볼륨의 파일도 삭제
      • Recycle : 영구 볼륨 클레임을 삭제할 때 영구 볼륨의 파일은 삭제를 하지만 영구 볼륨 자체는 삭제하지 않음
    • STATUS : 볼륨의 상태
      • Available : 아직 클레임에 바인딩되지 않은 상태
      • Bound : 볼륨이 클레임에 의해 바인딩 된 상태
      • Released :클레임이 삭제되었지만 클러스터에서 아직 리소스가 반환되지 않은 상태
      • Failed : 볼륨이 자동 반환에 실패한 상태
  • 볼륨을 자세히 보기 : kubectl describe pv mysql-pv-volume
  • 볼륨 클레임을 확인 :  kubectl get pvc
    • ACCESS MODES
    • RWO(Read Write Once) : 하나의 노드에서 해당 볼륨이 읽고 쓰기로 마운트
    • ROX(Read Only Many) : 많은 노드에서 해당 볼륨이 읽기로 마운트
    • RWX(Read Write Many_ : 많은 노드에서 해당 볼륨을 읽고 쓰기로 마운트
    • RWOP(Read Write Once Pod) : 단일 파드에서 읽고 쓰기로 마운트
  • mysql 접속
    • kubectl run --it --rm --image=mysql:latest --restart=Never mysql-client -- mysql -h mysql -ppassword
  • 접속이 되면 SQL 을 사용하여 데이터를 저장하는 것이 가능
    •  
CREATE DATABASE mySQL;
use mySQL;

CREATE TABLE Test(ID INT, Name VARCHAR(30) DEFAULT 'Anonymous', ReserveDate DATE, RoomNum INT);

SELECT *
FROM Test;

exit 명령으로 빠져나오기

 

  • 배포된 파드 삭제
    • kubectl delete deployment mysql
    • kubectl get pods
  • 파드를 다시 생성
    • kubectl apply -f pvc-deployment.yaml
  • mysql을 다시 접속
  • 이전에 만든 테이블을 확인 -> 존재

 

7. 파드를 외부에 노출시키기

 

7.1) 서비스

  • 파드는 클러스터 내의 노드들로 옮겨다니면서 생성
  • 파드를 식별할 수 있는 IP는 매번 수정되기 때문에 내부나 외부에서 접근하기가 어려움
  • 쿠버네티스의 서비스를 사용하면 파드가 클러스터 내 어디에 있든지 마치 고정된 IP로 접근할 수 있도록 해줌.
  • 서비스의 종류
    • 클러스터 내부 접속 용도 : ClusterIP
    • 클러스터 외부 접속 용도 : ExternalName, NodePort, LoadBalancer, Ingress ExternalName 은 내부에서 외부로 접근할 때 사용
      NodePort 는 외부에서 내부로 접근할 때 사용
      LoadBalancer 와 Ingress 는 여러 클러스터 사이에 접근도 가능

7.2) Cluster IP

  • 기본 서비스 타입
  • 클러스터 내부의 파드에 접근할 수 있는 가상의 IP
  • 서비스는 기본적으로 ClusterIP를 소유하고 서비스를 파드에 연결하면 서비스 IP를 통해서 파드에 접근할 수 있습니다.
  • Cluster IP를 부여하는 방법은 Service 유형을 설정하지 않고 Pod를 생성하기만 하면 됩니다.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: clusterip-nginx

spec:
  selector: 
    matchLabels:
      run: clusterip-nginx
  replicas: 2
 
  template:
    metadata:
      labels:
        run: clusterip-nginx
    spec:
      containers:
      - name : clusterip-nginx
        image: nginx

        ports:
        - containerPort: 80
  • 배포 : kubectl apply -f ClusterIP.yaml
  • 파드 확인 : kubectl get pods -l app=clusterip-nginx -o wide
  • 클러스터 내부에 다른 파드를 생성해서 현재 생성된 파드에 접근
    • 리눅스만 설치된 파드를 생성
    • kubectl delete pod busybox
    • kubectl run busybox --rm -it --image=busybox /bin/sh
  • 접속 완료!
    • 앞에서 확인한 Cluster IP를 이용해서 get 요청
    • wget 10.1.1.140 을 수행하면 index.html 을 받아오기
    • 브라우저 localhost로 10.1.1.141 에 접속하기(아직 안됨)
      • 클러스터 외부에서는 서비스를 만들어서 연결해주지 않으면 접근이 불가함.

 

7.3) External Name

  • 클러스터 내부에서 외부의 endpoint 에 접속하기 위한 서비스
  • 외부의 endpoint는 데이터베이스나 애플리케이션의 API 등을 의미
  • Service를 만들 때 spec 의 type 을 ExternalName 을 만들고 이름을 external-service 로 설정한 후 externalName을 myservice.test.com 으로 설정하면 external-service를 요청하면 myservice.test.com으로 리다이렉트 합니다.
  • 로드 밸런서가 이 서비스를 이용합니다.
  • 서비스를 만드는 방법
    • 매니페스트 파일을 생성(yaml)
    • kubectl expose 명령어를 사용하는 방법

7.4) NodePort

  • 노드포트 타입의 서비스는 외부 사용자(애플리케이션)가 클러스터 내부에 있는 파드에 접속할 때 사용하는 서비스
  • 특정 파드의 포트를 노트포트로 개방하면 노드포트 서비스가 이 포트로 들어오는 모든 요청은 해당 업무를 처리할 수 있는 파드로 전달
  • 워커 노드의 실제 IP가 192.168.0.1 이고 Cluster IP가 10.0.0.1 일 때 NODEPORT 30001 과 워커 노드의 파드를 연결시키면 외부에서는 192.168.0.1:30001 번이면 워커 노드의 파드에 접속합니다.
  • 매니페스트 파일을 만들어서 매핑을 하게 되는데 노드 포트 서비스를 하나 만들고 외부에서 어떤 포트로 접속할 지를 지정하고 내부의 어떤 파드를 사용할 지 셀렉터로 지정하고 포트를 설정하면 됩니다.
  • nginx 이미지를 가지고 파드를 생성할 매니페스트 파일을 작성 : nginx-deployment.yaml 
  • 파드 생성
    • kubectl apply -f nginx-deployment.yaml
  • deployment 와 파드 확인
    • kubectl get pods
    • kubectl get deployments
  • 노드포트 서비스를 위한 매니페스트를 작성: nginx-svc.yaml
  • 노드포트 서비스를 실행
    • kubectl apply -f ngingx-svc.yaml
  • 서비스 확인
    • kubectl get svc

 

 

 

 

 

 

 

반응형
LIST

'Docker' 카테고리의 다른 글

Kubenetes  (1) 2023.10.19
Docker(3)  (2) 2023.10.10
Docker  (2) 2023.10.04

관련글

티스토리툴바