20210901 (수) kubernetes ingress, volume

 

09:34 review

Ingress

 L7 LoadBalancer 기능을 제공하는 Kubernetes의 Object

 HTTP, HTTPS 프로토콜에 대한 처리 가능

 NodePort, LoadBalancer 타입의 서비스는 L4 수준에서 동작 → Ingress는 L7에서 동작

 NodePort, LoadBalancer 타입의 서비스 Object는 노출시키고자하는 애플리케이션 마다 생성 필요

  → Ingress Object는 하나의 Object로 처리 가능

  1) INGRESS multi path

  2) INGRESS multi host

 

vagrant@kube-control1:~$ cat myapp-ing-multi-host.yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: myapp-ing-multi-hosts
spec:
  rules:
  - host: web1.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: myapp-svc-ext-np1
          servicePort: 80
  - host: web2.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: myapp-svc-ext-np2
          servicePort: 80

vagrant@kube-control1:~$ cat myapp-ing-multi-path.yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: myapp-ing-multi-paths
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /web1
        backend:
          serviceName: myapp-svc-ext-np1
          servicePort: 80
      - path: /web2
        backend:
          serviceName: myapp-svc-ext-np2
          servicePort: 80

vagrant@kube-control1:~$ cat myapp-svc-ext-np1.yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc-ext-np1
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: myapp-web1
          
vagrant@kube-control1:~$ cat myapp-web1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp-web1
  labels:
    app: myapp-web1
spec:
  containers:
  - image: devops2341/go-myweb:latest
    name: myapp
    ports:
    - containerPort: 8080
      protocol: TCP
      
### ingress 리스트 확인 ###
vagrant@kube-control1:~$ kubectl get ingresses
Warning: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress
NAME                    CLASS    HOSTS                               ADDRESS          PORTS   AGE
myapp-ing               <none>   myapp.example.com                   192.168.200.22   80      7h17m
myapp-ing-multi-hosts   <none>   web1.example.com,web2.example.com   192.168.200.22   80      7m15s
myapp-ing-multi-paths   <none>   myapp.example.com                   192.168.200.22   80      109s
 
### multihosts ###
# 두 개의 서비스는 각각의 pod를 실행하고
# multi host를 이용해서 web1/web2 형태로 호스트 호출, 웹서비스 제공 가능

/etc/hosts #(root 권한으로 사전에 노드아이피 + host주소 등록 필요)

vagrant@kube-control1:~$ curl web1.example.com
Hello World!
myapp-web1
vagrant@kube-control1:~$ curl web2.example.com
Hello World!
myapp-web2

### multihosts ###
# 두 개의 서비스는 각각의 pod를 실행하고
# multi path를 이용해서 host/path1, host/path2 형태로 호스트 호출, 웹서비스 제공 가능
# 이때, 각각의 경로는 manifests에서 정의한 각각의 pods의 내용으로 실행되게 된다.

vagrant@kube-control1:~$ curl http://myapp.example.com/web1
Hello World!
myapp-web1
vagrant@kube-control1:~$ curl http://myapp.example.com/web2
Hello World!
myapp-web2

 

 

반응형

=======

 스토리지

 

 Volume : 

   pod의 저장공간 

 

 Volume 종류

  - emptyDir

  - gitRepo

  - hostPath

  - 네트워크 스토리지 볼륨

    cephfs, cinder, glusterfs, iscsi, nfs 등

  - 클라우드에서 제공하는 스토리지 볼륨

    awsElasticBlockStore, azureDisk, azureFile, gcePersistentDisk 등

 

  emptyDir 볼륨

    아무데이터도 없는 빈 디렉터리를 제공하는 Kubernetes 볼륨

    pod가 생성하는 데이터를 저장할 수 있으며, 동일 pod 내의 컨테이너 간 데이터 공유목적으로 간단히 사용

    pod가 종료되면 데이터도 삭제 : 임시로 데이터를 저장할 목적으로 사용

###문법### 
spec:
  containers:
  - volumeMounts:    # 볼륨 연결
    - name: VOLUME_NAME
        mountPath: MOUNT_PATH
  volumes:           # 볼륨 정의
  - name: VOLUME_NAME
    emptyDir: {}     # 볼륨 종류 지정

  getRepo 볼륨

    emptyDir 볼륨의 빈 볼륨에 최초 생성 시 git Repository의 데이터를 최초1회 복제하는 볼륨

    낮은 사용빈도로 인하여, deprecated 예정

 

  initContainer (초기화 컨테이너)

    애플리케이션 컨테이너가 실행되기 전에 초기화 작업을 수행하는 컨테이너

    pod가 생성되는 시점에 최초1회 초기화 작업을 수행 (애플리케이션 컨테이너보다 먼저 작업이 수행되는 컨테이너)

vagrant@kube-control1:~$ cat myapp-pod-gitrepo.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod-gitrepo
spec:
  initContainers:
  - name: git-clone
    image: alpine/git
    args:
    - clone
    - --single-branch
    - --
    - https://github.com/kubernetes/kubernetes
    - /repo
    volumeMounts:
    - name: git-repository
      mountPath: /repo
  containers:
  - name: git-container
    image: titiiscat/busybox:uploadtest
    args: ["tail", "-f", "/dev/null"]
    volumeMounts:
    - name: git-repository
      mountPath: /repo
  volumes:
  - name: git-repository
    emptyDir: {}
    
vagrant@kube-control1:~$ kubectl creat -f myapp-pod-gitrepo.yaml
vagrant@kube-control1:~$ kubectl describe pods myapp-pod-gitrepo
vagrant@kube-control1:~$ kubectl exec -ti myapp-pod-gitrepo -- sh
/ # cd repo/
/repo # ls

  hostPath 볼륨

    Kubernetes Cluster의 Node의 로컬 파일 시스템을 pod가 사용할 수 있도록 제공하는 볼륨

    pod 종료 시에도 데이터는 유지됨

    host(node)에 종속적인 볼륨이며, 노드가 다른 경우 기본적으로 데이터는 공유되지 않음

    각 host의 local 파일을 가르키고, 파일에 담긴내용이 다르면 결과물이 달라질 수 밖에 없음.

 

    *type : hostPath의 동작방식 결정 

    - DirectoryOrCreate : 지정한 디렉터리 사용 (해당 경로 디렉터리 없을 시 생성)

    - Directory : 지정한 디렉터리 사용 (반드시 해당디렉터리가 존재하는 상태에서만 작동)

    - FileOrCreate : 지정한 경로의 파일 사용 (해당 경로 파일 없을 시 생성)

    - File : 지정한 경로의 파일 사용 (반드시 해당파일이 존재하는 상태에서만 작동)

    - Socket : 지정한 경로의 Socket 사용 (반드시 해당파일이 존재해야함)

    - CharDevice : 지정한 경로의 Character Device 사용 (반드시 해당파일이 존재해야함)

    - BlockDevice : 지정한 경로의 Block Device 사용 (반드시 해당파일이 존재해야함)

    *path: hostPath의 경로 지정

 

### hostPath문법 ###
spec:
  volumes:
  - name: VOLUME_NAME
    hostPath:
      type: TYPE
      path: PATH
      
### 특정노드 지정 ###
  template:
    metadata:
      labels:
        app: myapp-rs-hostpath
    spec:
      nodeName: kube-node1   ##### 특정노드 지정 #####
      containers:
      - name: web-server
        image: nginx:alpine
        volumeMounts:
        - name: web-content
          mountPath: /usr/share/nginx/html

##### hostPath 실습 #####
#로컬의 /web_content 디렉터리를 읽어와서 /usr/share/nginx/html 에 마운트 하게되며,
#로컬에 index.html을 작성해둔 경우 웹접속(curl)시 해당 파일을 볼 수 있다.
# 단, 각각의 로컬에서 불러오므로 모든 노드에 해당 디렉터리/파일이 있거나 특정노드를 지정해줘야한다.


vagrant@kube-control1:~/work/20210901$ cat myapp-svc-hostpath.yaml #(서비스)
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc-hostpath
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: myapp-rs-hostpath

vagrant@kube-control1:~/work/20210901$ cat myapp-rs-hostpath.yaml #(replicaset)
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-rs-hostpath
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp-rs-hostpath
  template:
    metadata:
      labels:
        app: myapp-rs-hostpath
    spec:
      containers:
      - name: web-server
        image: nginx:alpine
        volumeMounts:
        - name: web-content
          mountPath: /usr/share/nginx/html
        ports:
        - containerPort: 80
          protocol: TCP
      volumes:
      - name: web-content
        hostPath:
          type: Directory
          path: /web_content

 

  PersistentVolume

    Kubernetes pod 및 controller에게 영구적인 저장공간을 제공하는 Volume

 

  PersistentVolumeClaim (PVC)

    1) Provisioning : PersistentVolume이 생성된 단계

    2) Binding : PersistentVolume(PV)이 PersistentVolumeClaim(PVC)와 연결되는 단계

    3) Using : PersistentVolumeClaim(PVC)이 제공한 볼륨을 pod에 연결하여 사용하는 단계

    4) Reclaiming : PVC가 종료/삭제되면 연결된 PersistentVolume(PV)을 회수하는 단계

 

  Reclaiming Policy

    - 유지 (Retain)

      PV 리소스를 그대로 유지하는 정책

      PVC와 연결이 끊겨도 다른 PVC와 연결될 수 없음

    - 삭제 (Delete)

      PVC 삭제 시 연결된 PV도 같이 삭제되는 정책

      PV가 같이 삭제되면서 외부 스토리지에 저장된 데이터도 같이 삭제됨

    - 재활용 (Recycle)

      스토리지의 데이터가 삭제되고 다른 PVC가 PV를 사용할 수 있도록 하는 정책

      현재 지원되는 스토리지는 NFS, hostPath 볼륨만 지원 가능함

      스토리지 종류마다의 구현이 복잡하여 향후 제거될 예정

 

   정적 Volume Provisioning

   동적 Volume Provisioning