[kubernetes] 네임스페이스별 서비스 및 마운트 실습

개념

볼륨(volume)

• 관리자가 볼륨제공, 요청을 동시에 수행한다.
• 관리자는 포드구성 및 포드내의 저장소 위치(IP, 디렉토리 명 등을 정확히 알고 있어야 한다.

PV/PVC

• PVC는 개발자가, PV는 관리자가 작성한다.
• PVC는 볼륨이 어떤 형태로 제공되는지(nfs? iscsi? ...)는 몰라도 된다. 필요한 볼륨의 유형과 크기만 작성하면 된다. (rw?, ro?, one to one, many to one, 1g, 10g)
• PV는 관리자가 nfs, iscsi 등을 이용하여 적절한 크기의 볼륨을 만들어 이를 pool에 보관한다.

admin.conf

cat /etc/kubernetes/admin.conf # 쿠버네티스 전체 관리자 admin
export KUBECONFIG=/etc/kubernetes/admin.conf # KUBECONFIG 환경변수에 저장
root@manager:~/k8slab# echo $KUBECONFIG
/etc/kubernetes/admin.conf

KUBECONFIG 는 service account 의 정보를 누구로 할 것인지 파일을 지정하는 변수
kubctl delete -f . # 현재 폴더에서 생성된 pod,svc, 모두 삭제

NFS

기본적으로 nfs의 공유 저장소에 외부 사용자가 접속하여 파일을 생성하게 되면 이 소유주는 "nfsnobody" 로 작성된다. 하지만 /etc/exports에 no_root_squash 가 옵션으로 작성

[실습]

선결조건

• metallb 가 준비된 상태이어야 한다. on-premise 환경에서 사용하기 어려운 service type LoadBalancer 를 포드 형태로 제공할 수 있는 방법
• 각 LB 별로 필요한 구성값을 추가하여 배포해야 한다.
• 생성된 포드에 볼륨을 연결할 계획이므로 master 에 nfs 서버가 구축되어 있어야 한다.
  (상태확인, 마운트 가능여부 확인을 위해 , node 에서 showmount -e 211.183.3.100)

시나리오.

• 우리는 kia, sk 의 서비스(서비스(nodeport/lb), deployment, volume) 을 관리해 주는 업체이다
• kia, sk 는 별도의 ns , address-pool on LB, mount point

1. nfs 에서의 구성

systemctl status nfs-server | grep Active: nfs-server 작동확인
chmod 777 /sk -R: 해당 디렉토리와 하위 디렉토리 모두 777로 설정
vi /etc/exports: 밑에 부분추가

/kia    211.183.3.0/24(rw,sync,no_root_squash)
/sk     211.183.3.0/24(rw,sync,no_root_squash)

systemctl restart nfs-server
showmount -e 211.183.3.100: worker에서 확인

2. namespace를 생성

mkdir lab1 ; cd lab1
touch kia-ns.yaml sk-ns.yaml
kubectl api-resources | grep Name:namespaces 버전확인
vi kia-ns.yaml: sk도 생성

apiVersion: v1
kind: Namespace
metadata:
  name: kia

yaml 파일이 아닌 명령어로 생성하는 방법: kubectl create ns sk

3. metallb를 이용하여 사용하게 될 LB의 주소 대역 지정하기

default: 211.183.3.201 - 211.183.3.210
kia: 211 ~ 220
sk: 221 ~ 230
metallb + configmap

vi lb-config.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 211.183.3.201-211.183.3.210
    - name: kia
      protocol: layer2
      addresses:
      - 211.183.3.211-211.183.3.220
    - name: sk
      protocol: layer2
      addresses:
      - 211.183.3.221-211.183.3.230

touch kia-deploy-svc.yaml sk-deploy-svc.yaml

4. 각 회사별 deploy-svc 생성/배포하기
   참고 : https://metallb.universe.tf/usage/

vi kia-deploy-svc.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: kia
  name: kia-deploy
spec: # RS
  strategy:
    type: Recreate
  replicas: 3
  selector:
    matchLabels:
      app: kia
  template: #POD
    metadata:
      labels:
        app: kia
    spec:
      containers:
      - name: kia-nginx
        image: nginx
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: kia-lb
  namespace: kia
  annotations:
    metallb.universe.tf/address-pool: kia
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: kia
  type: LoadBalancer

kubectl get deploy,svc
결과:service의 externel ip로 접속하면 nginx 로드. sk도 똑같이 구성

5. deploy 배포시 kia와 sk의 모든 포드는 각 포드의 /test 디렉토리를 각각 nfs 서버의 /kia, /sk 와 마운트되어야 한다.
   확인해야 할 사항

kubectl exec kia-deploy-5ccc6dc745-lbjbr -n kia -- ls/test
kubectl exec[포드이름] -n kia --ls /test
kia.txt <- 결과로 떠야 한다.

주의: 재부팅시 확인 할 것

kubectl get node
kubectl get pod -n kube-system (calico, api/scheduler/controller)
kubectl get pod -n metallb-system (controller, speaker)
위의 명령이 실행되지 않은다면 현재 계정은 kubernetes 환경에 대한 SA가 없는 상태다.
/etc/kubernetes/admin.conf
docker login