W13 Kubernetes 2/3

7 minute read

13주차부터 진행되었던 쿠버네티스의 학습 내역을 정리하였습니다.

Ingress
서비스 리소스 타입이 아니지만 서비스와 유사한 동작을 수행
동작하는 계층이 LoadBalancer, NodePort(4계층)와는 다름 (7계층)
서비스를 외부로 노출시키기 위한 경로를 제공
하나의 Ingress로 다수의 호스트에 대한 연결 제공 가능
하나의 Ingress로 호스트 내에서 경로에 대한 각각 연결 제공 가능
MSA(Micro Service Architecture)

인그레스 컨트롤러 테스트

환경구성) 인그레스의 백엔스 서비스 구성
컨트롤러1 - 서비스1
컨트롤러2 - 서비스2
컨트롤러3 - 서비스3
컨트롤러4 - 서비스4

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: rs1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-1
  template:
    metadata:
      labels:
        app: nginx-1
    spec:
      containers:
      - name: nginx-1-c
        image: nginx
        ports:
        - containerPort: 80
          protocol: TCP
apiVersion: v1
kind: Service
metadata:
  name: s1
spec:
  selector:
    app: nginx-1
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP


각 파드 별 컨텐츠 수정
kubectl exec -it <파드명> -- bash
echo S1 > /usr/share/nginx/html/index.html


인그레스 컨트롤러 리소스 생성
git clone https://github.com/kubernetes/ingress-nginx
cd ingress-nginx/deploy/static/provider/baremetal/1.21
kubectl create -f deploy.yaml


리소스 생성 후 확인
kubectl get all --namespace ingress-nginx
인그레스 서비스 설정 수정 (외부IP)
kubectl edit service --namespace ingress-nginx ingress-nginx-controller
…
spec:
  clusterIP: 10.101.33.12
  externalIPs:
  - 192.168.56.21
  - 192.168.56.22
  - 192.168.56.23
…



Ingress 리소스 생성
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-test
spec:
  rules:
  - host: app1.example.local
    http:
      paths:
      - path: /page1
        pathType: Exact
        backend:
          service:
            name: s1
            port:
              number: 80
      - path: /page2
        pathType: Exact
        backend:
          service:
            name: s2
            port:
              number: 80
  - host: app2.example.local
    http:
      paths:
      - path: /page1
        pathType: Exact
        backend:
          service:
            name: s3
            port:
              number: 80
      - path: /page2
        pathType: Exact
        backend:
          service:
            name: s4
            port:
              number: 80


요청 테스트
ingress 서비스의 cluster ip 확인
kubectl get service --namespace ingress-nginx
확인한 주소로 curl 요청
curl -v --resolve app1.example.local:80:10.105.34.139 http://app1.example.local/page1

주요 키워드

K8s

Volume

emptyDir
hostpath

수업 정리

볼륨
쿠버네티스의 파드에서 저장소를 제공하는 기능
기본적인 파드의 특성인 Stateless 으로 인해 데이터가 유지되지 않으므로, 데이터를 파드의 라이프사이클과 별개로 유지하기 위해서는 별도의 볼륨이 필요
파드 내 컨테이너 간 공유 저장소 기능 제공

쿠버네티스의 볼륨 유형
emptyDir
파드의 라이프사이클과 같이하는 볼륨
임시공간으로 파드 내 컨테이너 간 공유 목적으로 사용
hostPath
도커의 BindMount 와 유사한 개념
파드에게 호스트의 파일시스템을 볼륨으로 제공
네트워크 볼륨
nfs 등 네트워크를 통해 접근 가능한 파일시스템을 볼륨으로 제공
클라우드 볼륨
클라우드 서비스에서 제공하는 저장소를 볼륨으로 제공
영구 볼륨(PersistentVolume)
볼륨 사용 시 관리자의 관리영역과 사용자의 관리영역을 분리하는 볼륨
정적 : 관리자에 의해 사전에 생성된 볼륨을 사용
동적 : 사용자의 요청에 의해 자동으로 생성되는 볼륨을 사용
특수 볼륨
ConfigMap
Secret
EmptyDir
아무런 데이터가 들어있지 않은 빈 공간을 제공
파드 내 컨테이너 간 공유 저장소를 사용할 수 있음

볼륨 사용을 위한 리소스 오브젝트 기본 구조
apiVersion: v1
kind: Pod
metadata:
  name: testpod
spec:
  containers:
  - name: test-pod-container
    image: ubuntu
    volumeMounts:
    - name: <VOLUME_NAME>
      mountPath: <MOUNTPOINT>
  volumes:
  - name: <VOLUME_NAME>
    <VOLUME_TYPE>


emptyDir 예시
apiVersion: v1
kind: Pod
metadata:
  name: testpod
spec:
  containers:
  - name: test-pod-container
    image: ubuntu
    command:
    - sleep
    - infinity
    volumeMounts:
    - name: emptydir-vol
      mountPath: /test
  volumes:
  - name: emptydir-vol
    emptyDir: {}



emptyDir 볼륨 사용 예시
apiVersion: apps/v1
kind: Deployment
metadata:
  name: emptydir-share-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: fortune
  template:
    metadata:
      labels:
        app: fortune
    spec:
      containers:
      - name: webserver
        image: nginx:latest
        volumeMounts:
        - name: share-vol
          mountPath: /usr/share/nginx/html
          readOnly: true
        ports:
        - containerPort: 80
          protocol: TCP
      - name: fortune
        image: ghcr.io/c1t1d0s7/fortune
        volumeMounts:
        - name: share-vol
          mountPath: /var/htdocs
      volumes:
      - name: share-vol
        emptyDir: {}



참고) gitRepo 볼륨
git으로부터 필요한 데이터를 받아와서 초기화되는 볼륨
현재는 사용하지 않음
필요할 경우 emptyDir + InitContainer 조합으로 사용

InitContainer
실제 파드 운영상 필요한 파드가 아니라 파드 초기화 단계에서 필요한 파드
apiVersion: v1
kind: Pod
metadata:
  name: gitrepo-test
spec:
  initContainers:
  - name: git-container
    image: alpine/git
    args:
    - clone
    - https://github.com/kubernetes-sigs/kubespray.git
    - /git
    volumeMounts:
    - name: git-vol
      mountPath: /git
  containers:
  - name: test-container
    image: busybox
    command:
    - sleep
    - infinity
    volumeMounts:
    - name: git-vol
      mountPath: /git
  volumes:
  - name: git-vol
    emptyDir: {}




HostPath
Docker Bind Mount와 유사한 동작 방식을 가짐

hostPath 예시

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: hostpath-rs
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - name: hostpath-rs-container
        image: ubuntu
        command:
        - sleep
        - infinity
        volumeMounts:
        - name: hostpath-vol
          mountPath: /hostpath
      volumes:
      - name: hostpath-vol
        hostPath:
          type: DirectoryOrCreate
          path: /tmp/hostpath
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: webserver-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      containers:
      - name: webserver
        image: nginx:latest
        volumeMounts:
        - name: web-contents
          mountPath: /usr/share/nginx/html
          readOnly: true
        ports:
        - containerPort: 80
          protocol: TCP
      volumes:
      - name: web-contents
        hostPath:
          type: Directory
          path: /web_contents

K8s

Volume

NFS
Persistent Volume
Storage Classes
- Rook

수업 정리

네트워크 기반 볼륨 (nfs)

nfs 서버 기능 설치 (kube-control1 에서)
패키지 설치
sudo apt-get update
sudo apt-get install nfs-kernel-server
공유용 디렉토리 생성
sudo mkdir /nfs-share
sudo chmod 777 /nfs-share/
nfs 설정 변경
sudo vi /etc/exports
/nfs-share      *(rw,sync,no_subtree_check)
nfs 서비스 재시작
sudo systemctl restart nfs-kernel-server.service
nfs 클라이언트 기능 설치 (kube-node1~3 에서)
클라이언트 기능 설치
sudo apt -y install nfs-common
nfs 서버 연결 확인
showmount -e 192.168.56.11

nfs 볼륨을 사용하는 파드를 생성하는 ReplicaSet 예시
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: webserver-rs-nfs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: webserver
        image: nginx:latest
        volumeMounts:
        - name: web-contents
          mountPath: /usr/share/nginx/html
          readOnly: true
        ports:
        - containerPort: 80
          protocol: TCP
      volumes:
      - name: web-contents
        nfs:
          server: 192.168.56.11
          path: /nfs-share


각 파드의 웹 서비스에서 사용할 index.html 파일 생성 (kube-control1에서)
echo "Hello my nfs index.html" > /nfs-share/index.html

nfs 사용 파드 생성 후 웹서비스 페이지 확인
kubectl create -f nfsvol-rs.yaml
kubectl get pod -o wide
curl <파드IP>


영구 볼륨(Persistent Volume)
볼륨에 대한 설정을 하는 부분과 사용하는 부분을 분리
역할에 따른 리소스 분류
PersistentVolume: 사용할 볼륨의 구체적 설정
PersistentVolumeClaim: 볼륨을 사용하기 위한 설정

PV와 PVC의 생명주기
프로비저닝(Provisioning)
관리자에 의해 PV리소스가 생성되고, 사용할 수 있도록 구성된 상태
바인딩(Binding)
PV와 PVC가 연결되는 상태. PV와 PVC는 1:1로 매칭
사용(Using)
바인딩 된 PV와 PVC를 통해 볼륨을 사용
회수(Reclaim)
PV와 PVC의 바인딩이 해제된 상태. PV의 회수정책에 따라 정리 실시

회수 정책
유지 (Retain)
PV 리소스가 그대로 유지됨 (데이터가 유지됨
PVC를 다시 생성하여 연결할 수는 없음
데이터의 보존을 위해서는 관리자가 직접 PV의 저장소를 접근하여 데이터를 백업
삭제 (Delete)
PV와 PVC의 바인딩 상태에서 PVC가 삭제될 경우 PV는 자동으로 삭제
클라우드에서 제공되는 스토리지 (AWS, GCP, Azure)
재사용 (Recycle)
기존에 사용중인 PV의 바인딩이 해제되었을 때, 재사용 가능
앞으로 사라질 예정



nfs 사용한 정적 영구볼륨 설정

기본 구성
nfs - PV - PVC - Pod


PV 리소스의 accessModes 종류
ReadWriteOnce: 하나의 파드만 읽기 쓰기 가능
ReadWriteMany: 다수의 파드가 읽기 쓰기 가능
ReadOnlyMany: 다수의 파드가 읽기만 가능

PV리소스의 회수정책 persistentVolumeReclaimPolicy
Retain: 유지
Delete: 삭제
Recycle: 재사용

PV 리소스 예시
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv-vol
spec:
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    server: 192.168.56.11
    path: /nfs-share


PV 상태 확인
kubectl get persistentvolumes

PV의 상태
Available: PV가 생성되어 PVC에 연결할 수 있는 상태
Bound: PV와 PVC가 연결된 상태, PVC를 통해 볼륨을 사용할 수 있는 상태
Released: PVC와 연결이 해제된 상태. 회수를 필요로 하는 상태
Failed: 정상적으로 회수가 되지 않은 상태


PVC 리소스 생성
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-nfs-vol
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi
  volumeName: nfs-pv-vol



PV를 사용하는 레플리카셋 예시
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nfs-pv-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx-container
        image: nginx
        ports:
        - containerPort: 80
          protocol: TCP
        volumeMounts:
        - name: nfs-pvc
          mountPath: /usr/share/nginx/html
      volumes:
      - name: nfs-pvc
        persistentVolumeClaim:
          claimName: pvc-nfs-vol


레플리카셋의 각 파드에서 볼륨 연결 상태 확인
kubectl describe pod <파드이름>

PVC리소스의 정보에서 PVC를 사용중인 파드 확인
kubectl describe persistentvolumeclaim <PVC이름>


PV 회수
PVC를 사용중인 파드를 삭제하기 위해 레플리카셋 삭제
kubectl delete rs <레플리카셋이름>
파드가 모두 삭제된 후 PVC 리소스 삭제
kubectl delete pvc <PVC 리소스 이름>
PV 리소스 상태 확인 (Released)
kubectl get pv
다시 PVC 리소스 생성하여 기존 PV 연결 가능한지 확인
kubectl create -f <PVC파일>
PV와 PVC 리소스 상태 확인 (Bound 되지 않음)
kubectl get pv,pvc
PV리소스 삭제 후 재생성
kubectl delete pv <PV리소스이름>
kubectl create -f <PV파일>
PV와 PVC 리소스 재확인
kubectl get pv,pvc

컨피그맵(Config Map, ConfigMap)

컨피그맵 및 시크릿은 모두 키/값 형태의 데이터를 저장하는 리소스
etcd 저장소에 저장
쿠버네티스 클러스터 내에서 자유롭게 접근이 가능한 데이터를 저장

컨피그맵 리소스 생성

명령어 사용
- 옵션에 키와 값을 입력
- kubectl create configmap myconfigmap1 –from-literal=key1=value1 - 파일의 내용을 값으로 사용하고 옵션으로 지정한 파일명이 키로 지정
- echo value2 > key2
- kubectl create configmap myconfigmap2 –from-file=key2 - 파일의 내용을 값으로 사용하고, 옵션에서 파일을 지정하며 별도로 키를 입력
- echo value3 > data.txt
- kubectl create configmap myconfigmap3 –from-file=key3=data.txt - 디렉토리 내 파일들의 이름을 키, 내용을 값으로 지정
- mkdir data
- echo value4 > data/key4
- echo value5 > data/key5.txt

오브젝트 파일 사용

  apiVersion: v1
  kind: ConfigMap
  metadata:
 name: myconfigmap5
  data:
 key6: value6
 key7: value7

컨피그맵 사용 예시

kubernetes 클러스터 coredns 설정
kubectl describe configmaps –namespace kube-system coredns

Nasir

W13 Kubernetes 2/3

수업 정리

수업 정리

컨피그맵(Config Map, ConfigMap)

Leave a comment