Kubernetes

# k get pod -A -o wide NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES default nginx-pod 1/1 Running 0 11m 192.168.12.217 ip-192-168-12-150.ap-northeast-2.compute.internal <none> <none> karpenter karpenter-5bffc6f5d8-6f779 1/1 Running 0 125m 192.168.12.99 fargate-ip-192-168-12-99.ap-northeast-2.compute.internal <none> <none> karpenter karpenter-5bffc6f5d8-84mjn 1/1 Running 0 130m 192.168.11.201 fargate-ip-192-168-11-201.ap-northeast-2.compute.internal <none> <none> kube-system aws-node-h5z8d 1/1 Running 0 11m 192.168.12.150 ip-192-168-12-150.ap-northeast-2.compute.internal <none> <none> kube-system coredns-fd69467b9-4nk6x 1/1 Running 0 127m 192.168.12.52 fargate-ip-192-168-12-52.ap-northeast-2.compute.internal <none> <none> kube-system coredns-fd69467b9-cqqpq 1/1 Running 0 125m 192.168.11.122 fargate-ip-192-168-11-122.ap-northeast-2.compute.internal <none> <none> kube-system kube-proxy-z8qlj 1/1 Running 0 11m 192.168.12.150 ip-192-168-12-150.ap-northeast-2.compute.internal <none> <none> ```bash 먼저 예제를 보여준다. NodeLess EKS 컨셉의 기반이다. nginx-pod / aws-node-h5z8d / kube-proxy-z8qlj 는 카펜터가 만든 노드위에 올라가 있다. NodeLess 의 컨셉은 두가지를 기반으로 한다. 쿠버네티스 컴포넌트 kube-system namespace Pod들은 Fargate에 올린다. 여기에 에드온이나 관리가 필요한 Pod도 포함된다. karpenter controller라던가..AWS ELB Controller 라던가 그런 에드온들이 그런 역할을 한다. Node가 필요한 Pod는 NodeGroup을 사용하지 않고 Karpenter를 사용한다. 그럼 NodeGroup이 없는 클러스터부터 만드는 방법이다. <https://eksctl.io/usage/fargate-support/> ```bash eksctl create cluster --fargate ```bash 간단하다 옵션으로 --fargate를 주면된다. Fargate profile 같은경우에는 사실 콘솔에서 손으로 만들면 편하다. subnet이나 iam role 넣어주는게....그렇지 않다면 먼저 aws cli 부터 학습해야 한다. eksctl이 자동으로 해주는 부분도 있지만 필수요소는 알아야 하기 때문이다. <https://awscli.amazonaws.com/v2/documentation/api/latest/reference/eks/create-fargate-profile.html> ```bash aws eks create-fargate-profile --fargate-profile-name kube-system --cluster-name myeks --pod-execution-role-arn arn:aws:iam::123456789:role/AmazonEKSFargatePodExecutionRole --subnets "subnet-1" "subnet-2" "subnet-3" ```bash <https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/pod-execution-role.html> 역할생성은 이링크를 참고한다. 이런식으로 만들고 파게이트는 네임스페이스로 지정하면 네임스페이스에 만들어지는 톨레이션이나 다른 노드 어피니티등을 가지지 않은 Pod를 Fargate로 프로비저닝 한다. 이때 일반적인 쿠버네티스와 다른 부분은 Fargate 스케줄러(fargate-scheduler)가 별도로 동작하여 Fargate를 프로비저닝한다. 일반적인 경우엔 (default-scheduler)가 Pod를 프로비저닝 한다. 이 차이를 알아두면 어떤 노드를 물고있는지 확인하기 편하다.

EKS의 관리영역중 Addon 이나 필수 컴포넌트중에 Node에서 동작해야하는 것들이 있다. 이 경우에 NodeGroup을 운영해야한다. NodeGroup에 여러 파드들이 스케줄링되고 관리형 Pod들은 다른 서비스에 운영되는 NodeGroup과 섞여서 스케줄리되어야 하는데, 이것의 가장큰 문제는 Node의 사망이 기능의 장애로 이어진다는 점이다. 따라서 Node를 전용 Node로 사용하면 좋은데 아주작은 노드를 스케줄링한다고 해도 관리되어야 하는 대상이 됨은 틀림없고, 노드를 정해서 사용해야 하는 문제점들이 생기게된다. 이러한 문제를 해결하기에 EKS에서는 Fargate가 있다. 1Node - 1Pod 라는게 아주 중요한 포인트다. ...

마지막 주차이다. 5 주차는 보안 관련한 주제였다. 대표적으로 생각나는 쿠버네티스 보안 사건부터 이야기할까한다. 생각보다 많은 사람들이 쓰는 오픈소스중에 Rancher가 있다. Rancher가 설치된 클러스터에서 이상한 증상이 발생했다. 배포된 POD가 재대로 성능이 나지않고 WorkerNode의 CPU사용율이 굉장히 높았다. 클러스터 외부에서 원인을 파악할 수 없어서 결국 WokerNode에 SSH를 접속해서 확인했었다. WorkerNode에선 대량의 마이닝툴이 발견되었다. Pirvate 환경인데다가 외부에서 SSH도 불가능한 환경에서 발생한 침해사고라, 플랫폼의 문제로 대두되었다. 그러던 중 클러스터에서 동작중인 대시보드들을 확인하였다. 당시에는 다들 쿠버네티스에 익숙한 상황이 아니라서 확인이 좀오래 걸렸다. ...

이번주 스터디는 K8S에서의 Pometheus Grafana 다. 이글은 chatgpt를 이용해서 삽질하는 리눅서를 담고있다. 프로메테우스는 아이콘이 불꽃 모양인데 정말 모니터링계에 불을 가져다준 혁신과도 같은 존재다. 이전에는 Nagios / Zabbix가 나눠먹고 있었다. 나는 이번에 뭘 모니터링 해볼까 고민하다가 HPA를 모니터링 해볼까한다. 먼저 내가 요즘 일하는 방식을 보여줄까한다. 바로 Chatgpt다. apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.21 ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 type: LoadBalancer ```bash  ```bash apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: nginx-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginx-deployment minReplicas: 3 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50 ```bash  <https://github.com/rakyll/hey> go 기반이라 bash로 수정해달라고 했다.  ```bash #!/bin/bash SERVICE_IP=$(kubectl get svc nginx-service -o jsonpath='{.status.loadBalancer.ingress[0].ip}') CONCURRENCY=100 REQUESTS=50000 # Run load test for i in $(seq 1 $CONCURRENCY); do (for j in $(seq 1 $(($REQUESTS / $CONCURRENCY))); do curl -s -o /dev/null http://${SERVICE_IP}/ done) & done # Wait for all background processes to complete wait ```bash 위의 Manifast 를 적용한 결과는 다음과 같다. ```bash k get all NAME READY STATUS RESTARTS AGE pod/nginx-deployment-7c6895c677-cblrh 1/1 Running 0 15s pod/nginx-deployment-7c6895c677-s6b5c 1/1 Running 0 15s pod/nginx-deployment-7c6895c677-smkxv 1/1 Running 0 15s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/nginx-service LoadBalancer 100.66.65.216 <pending> 80:30979/TCP 15s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/nginx-deployment 3/3 3 3 15s NAME DESIRED CURRENT READY AGE replicaset.apps/nginx-deployment-7c6895c677 3 3 3 15s NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE horizontalpodautoscaler.autoscaling/nginx-hpa Deployment/nginx-deployment <unknown>/50% 3 10 3 19s ```bash 정말 잘동작한다. 이제 ingress 답변을 받았다. ```bash apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress annotations: kubernetes.io/ingress.class: alb alb.ingress.kubernetes.io/scheme: internet-facing spec: rules: - http: paths: - path: / pathType: Prefix backend: service: name: nginx-service port: number: 80 ```bash ```bash k get ingress NAME CLASS HOSTS ADDRESS PORTS AGE my-ingress <none> * k8s-nginx-myingres-106681c1f1-1873214288.ap-northeast-2.elb.amazonaws.com 80 72s ```bash ingress - svc - deployment - hpa 구조 같은건 이제 3분이면 나온다. gpt가 알려준 스크립트중 kubectl get svc nginx-service -o jsonpath='{.status.loadBalancer.ingress[0].ip}' 부분을 kubectl get ingress my-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}' 다음과 같이 수정하였다. ```bash curl k8s-nginx-myingres-106681c1f1-1873214288.ap-northeast-2.elb.amazonaws.com <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> html { color-scheme: light dark; } body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html> ```bash 잘 뜬다. 이제 공격 간다  굉장한 스크립트 였다... 한방에 100개의 스크립트가 떴다...후.... 근데 nginx 는 너무 가벼운 친구라...ㅠㅠ hpa 가 잘작동하지 않았다. 리미트를 준다. ```bash resources: limits: cpu: 15m memory: 10Mi requests: cpu: 15m memory: 10Mi k get hpa NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE nginx-hpa Deployment/nginx-deployment 33%/50% 3 10 3 25m ```bash 좋다 적절하다. 이제 셋업은 다되었다. hpa 가 동작하는 대시보드와 hap 가 일정이상 동작해서 max 에 가 까워지면 알럿을 날릴거다.  Chatgpt에게 물었고, 비슷한 쿼리를 작성했다. ```bash kube_horizontalpodautoscaler_status_desired_replicas{horizontalpodautoscaler="nginx-hpa", namespace="nginx"} ```bash  결과는 잘 작동한다. 그럼이걸 알럿을 보낼거다. 프로메테우스에서 graph로 grafana 에서 가져온 쿼리를 넣는다  1- avg(rate(kube_horizontalpodautoscaler_status_desired_replicas{horizontalpodautoscaler="nginx-hpa", namespace="nginx"}[1m])) ```bash k edit cm prometheus-kube-prometheus-stack-prometheus-rulefiles-0 configmap/prometheus-kube-prometheus-stack-prometheus-rulefiles-0 edited ```bash  edit 로 수정했다. 추가를 하다가 잘 안되서 helm에 있는 config를 뜯어봤다. 어떤구성인지, ```bash containers: - env: - name: BITNAMI_DEBUG value: "false" - name: NGINX_HTTP_PORT_NUMBER value: "8080" image: docker.io/bitnami/nginx:1.23.3-debian-11-r17 imagePullPolicy: IfNotPresent livenessProbe: failureThreshold: 6 initialDelaySeconds: 30 periodSeconds: 10 successThreshold: 1 tcpSocket: port: http timeoutSeconds: 5 name: nginx ports: - containerPort: 8080 name: http protocol: TCP readinessProbe: failureThreshold: 3 initialDelaySeconds: 5 periodSeconds: 5 successThreshold: 1 tcpSocket: port: http timeoutSeconds: 3 resources: {} terminationMessagePath: /dev/termination-log terminationMessagePolicy: File - command: - /usr/bin/exporter - -nginx.scrape-uri - http://127.0.0.1:8080/status image: docker.io/bitnami/nginx-exporter:0.11.0-debian-11-r44 imagePullPolicy: IfNotPresent livenessProbe: failureThreshold: 3 httpGet: path: /metrics port: metrics scheme: HTTP initialDelaySeconds: 15 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 5 name: metrics ports: - containerPort: 9113 name: metrics protocol: TCP readinessProbe: failureThreshold: 3 httpGet: path: /metrics port: metrics scheme: HTTP initialDelaySeconds: 5 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1 resources: {} terminationMessagePath: /dev/termination-log terminationMessagePolicy: File dnsPolicy: ClusterFirst restartPolicy: Always schedulerName: default-scheduler securityContext: {} serviceAccount: default serviceAccountName: default shareProcessNamespace: false terminationGracePeriodSeconds: 30 ```bash exporter 가 사이드카로 붙어서 모니터링을 하고있었다. <https://github.com/nginxinc/nginx-prometheus-exporter> 온종일 삽질의 연속이다가 오늘또 k8s에서의 프로메테우스와 그라파나 패턴을 까보면서 helm을 써야할까 하는 고민이들었다. kustomize를 고민했는데 좀더 뭘깍을지 생각해봐야겠다.

이글은 Argo WorkFlow로 CI를 하려했던 나의 경험담을 담고있다. Argo WorkFlow를 쓰려고 결심하고 리서칭하는 중이라면 AirFlow가 있다. 돌아가라. Argo WorkFlow는 Flow마다 Pod를 생성한다. 그대가 원하는 패턴이 맞는지 다시한번 생각하라. 매 Flow 마다 Pod가 만들어 지는것이 맞는가? 그렇다면 맞다 Argo WorkFlow 다. 그럼다면 다시 묻는다 CI를 위해서 Argo를 찾는것인가? K8S에서 다양한 CRD에 익숙하고 강력한 러닝커브는 즐거움으로 생각되고 CNCF에 기여하는게 꿈이라면 말리지 않겠다. 잘왔다. Argo WorkFlow/Events다. 이 글에선 CI를 다룬다. 물론 글이 깊진 않다. 하지만 찍먹으론 충분한 수준으로 그대에게 전달할 것이다. 먼저 Argo-WorkFlow 를 설치해야한다. ...

ㅠㅠ 울고 시작하려한다. 스터디에 집중을 하려고 한다. 가시다님 그동안 숙제 너무 조금해서 죄송했어요…ㅠㅠ엉엉흑흑 일단 사과를 드리고 시작하며, 이제 살짝 각잡고 kOps 부터 설명하겠다. kOps는 Kubernetes Operations의 약자로, Kubernetes 클러스터를 AWS (Amazon Web Services)에서 손쉽게 설치, 업그레이드 및 관리할 수 있도록 해주는 오픈 소스 도구이다. Kops를 사용하면 CLI(Command Line Interface)를 통해 클러스터를 구성할 수 있으며, YAML 파일을 사용하여 쉽게 클러스터를 정의할 수 있다 Kops는 여러 가지 기능을 제공한다 클러스터 구성: Kops를 사용하여 Kubernetes 클러스터를 쉽게 구성할 수 있다. YAML 파일을 사용하여 클러스터 구성을 정의하고, AWS 리소스를 프로비저닝하고 구성을 배포한다. ...

spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 resources: limits: cpu: 500m requests: cpu: 200m lifecycle: preStop: exec: command: ["/bin/sleep", "30"] ```bash . . hpa 발생시 pod의 갑작스런 종료로 pod에 연결된 사용자가 502를 받게된다. 모든 리퀘스트를 처리 후에 종료되도록 30초간의 유예를 준다 설정 변경 lifecycle preStop 를 이용하여 우아한 종료를!

이번에 스터디에 참가하게 되었다. 가시다님의 PKOS! 스터디할시에 사용하는 책은 24단계 실습으로 정복하는 쿠버네티스 이다. kOps를 프로비저닝하는데 오타가 발생해서 심심해서 스크립트를 만들었다. 그덕에 한번 다시 만들었다. #!/bin/bash echo "클러스터명-도메인을 입력해주세요 : " read KOPS_CLUSTER_NAME echo "버킷명을 입력해 주세요 s3:// 는 입력하지 않아도 됩니다. : " read KOPS_STATE_STORE # Access Key를 입력 받음 read -p "엑세스키를 입력해주세요 : " ACCESS_KEY # Secret Access Key를 입력 받음 read -p "시크릿키를 입력해주세요 : " SECRET_KEY # AWS 계정 구성 aws configure set aws_access_key_id $ACCESS_KEY aws configure set aws_secret_access_key $SECRET_KEY echo 'export AWS_PAGER=""' >>~/.bashrc echo "export REGION=ap-northeast-2" >>~/.bashrc echo "export KOPS_CLUSTER_NAME=$KOPS_CLUSTER_NAME" >>~/.bashrc echo "export KOPS_STATE_STORE=s3://$KOPS_STATE_STORE" >>~/.bashrc kops create cluster --zones="$REGION"a,"$REGION"c --networking amazonvpc --cloud aws \\ --master-size t3.medium --node-size t3.medium --node-count=2 --network-cidr 172.30.0.0/16 \\ --ssh-public-key ~/.ssh/id_rsa.pub --name=$KOPS_CLUSTER_NAME --kubernetes-version "1.24.10" --dry-run -o yaml > mykops.yaml kops create cluster --zones="$REGION"a,"$REGION"c --networking amazonvpc --cloud aws \\ --master-size t3.medium --node-size t3.medium --node-count=2 --network-cidr 172.30.0.0/16 \\ --ssh-public-key ~/.ssh/id_rsa.pub --name=$KOPS_CLUSTER_NAME --kubernetes-version "1.24.10" -y source <(kubectl completion bash) echo 'source <(kubectl completion bash)' >> ~/.bashrc echo 'alias k=kubectl' >> ~/.bashrc echo 'complete -F __start_kubectl k' >> ~/.bashrc ```bash read 명령어를 이용하여 스크립트에 변수를 부여하고 입력받은 변수를 이용하여 aws configure 를 설정하고, kops 명령어로 k8s 클러스터를 프로비저닝한다. 이거다음에는 사실 initscript 에 내가원하는 값을 넣는게 제일 편하나 그건..좀 공개하기 애매하니 스크립트라도 공개한다.

Mysql Operator 스터디를 진행중에 느꼈다. Mysql Operator는 현재 나의 판단보다 Operator의 로직이 훨신 빠르고 정확하게 동작할거라는 생각이 들었다. 다른말로는 믿고 써도 될수준에 가깝다 느껴졌다. 물론 RDS 못잃어 https://dev.mysql.com/doc/mysql-operator/en/mysql-operator-introduction.html 그래서 나는 실습은 그냥..helm으로 다들 하는것 같아서 Operator가 생성하는 Mysql Cluster 의 아키텍처를 파해쳐 볼까한다. DNS - SRV Record https://www.haproxy.com/documentation/hapee/latest/management/service-discovery/dns-service-discovery/discovery-with-srv-records/ SRV 레코드는 자주 사용 되는 레코드는 아니지만, GSLB혹은 가중치를 이용한 라우팅, 페일오버 등에 사용된다. https://blog.o3g.org/network/dns-record/ 수진님의 포스팅 링크 https://dev.mysql.com/doc/refman/8.0/en/connecting-using-dns-srv.html 정리하자면 Mysql Routor 에서 클러스터의 노드별로 srv레코드를 부여하고, ...

가시다님과 함께하는 스터디는 항상 즐겁다. 이번 스터디엔 라이브로 못해서..일단 바닐라쿠버 배포하고 시작했다. Headless 서비스는 ClusterIP가 None으로 설정하며 kubeproxy를 통하지않고 pod의 endpoint가 svc에 연결된다. 나는 먼저 NFS 서버를 Headless 로 배포하기로 했다. kind: PersistentVolumeClaim apiVersion: v1 metadata: name: nfs-server-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi --- kind: Service apiVersion: v1 metadata: name: nfs-service spec: type: ClusterIP clusterIP: None selector: role: nfs ports: # Open the ports required by the NFS server # Port 2049 for TCP - name: tcp-2049 port: 2049 protocol: TCP # Port 111 for UDP - name: udp-111 port: 111 protocol: UDP # Port 20048 for TCP - name: tcp-20048 port: 20048 protocol: TCP --- apiVersion: v1 kind: ReplicationController metadata: name: nfs-server spec: replicas: 1 selector: role: nfs-server template: metadata: labels: role: nfs-server spec: containers: - name: nfs-server image: gcr.io/google_containers/volume-nfs:0.8 ports: - name: nfs containerPort: 2049 - name: mountd containerPort: 20048 - name: rpcbind containerPort: 111 securityContext: privileged: true volumeMounts: - mountPath: /exports name: nfs-export volumes: - name: nfs-export-fast persistentVolumeClaim: claimName: nfs-server-pvc-fast ```bash ? yaml을 deploy 하면 다음과같다. 이제 프로비저너 셋팅이 좀 필요하다. 가시다님께서는 친절하게 프로비저너 셋팅도 다해주셨지만 나는 내가만든 NFS 서버를 사용할거기 때문에 프로비저너를 다시 배포할거다. ```bash #지우고 helm delete -n kube-system nfs-provisioner #다시 설치하고 helm install nfs-provisioner -n kube-system nfs-subdir-external-provisioner/nfs-subdir-external-provisioner --set nfs.server=nfs-service.default.svc.cluster.local --set nfs.path=/exports NAME: nfs-provisioner LAST DEPLOYED: Thu May 26 16:10:31 2022 NAMESPACE: kube-system STATUS: deployed REVISION: 1 TEST SUITE: None ```bash ? 응 잘됬다. ```bash (? |DOIK-Lab:default) root@k8s-m:~# k get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.200.1.1 <none> 443/TCP 4h30m nfs-service ClusterIP None <none> 2049/TCP,111/UDP 6m29s (? |DOIK-Lab:default) root@k8s-m:~# k get ep NAME ENDPOINTS AGE kubernetes 192.168.10.10:6443 4h30m nfs-service 172.16.158.2:2049,172.16.158.2:111 6m48s (? |DOIK-Lab:default) root@k8s-m:~# k get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nfs-server-pod 1/1 Running 0 7m1s 172.16.158.2 k8s-w1 <none> <none> ```bash ? 정상적으로 NFS서버가 잘 배포된것을 확인할수 있다. ```bash apiVersion: v1 kind: PersistentVolume metadata: name: mysql-nfs-pv labels: type: mysql-nfs-pv spec: storageClassName: nfs-client capacity: storage: 4Gi accessModes: - ReadWriteOnce # ReadWriteOnce RWO (1:1 마운트, 읽기 쓰기) nfs: server: 172.16.184.9 # NFS-Server 의 IP path: /1 # NFS 저장소 --- apiVersion: v1 kind: PersistentVolume metadata: name: wp-nfs-pv labels: type: wp-nfs-pv spec: storageClassName: nfs-client capacity: storage: 4Gi accessModes: - ReadWriteOnce nfs: server: 172.16.184.9 # NFS-Server 의 IP path: /2 # NFS 저장소 ```bash ? nfs-service.svc.cluster.local domain을 이용하려 하였으나, PV 에서 domain으로 설정시 nfs-provisioner 정상적으로 마운트 되지 않았다. **headless NFS를 하려고 한것이나, 실패하였다. 지원하지 않는다.(결론)**  다음과 같은 증상이었다. IP로 프로비저너 설치후엔 잘되었다. ```bash --- apiVersion: v1 kind: PersistentVolumeClaim metadata: labels: app: wordpress name: mysql-pv-claim spec: storageClassName: nfs-client accessModes: - ReadWriteOnce resources: requests: storage: 4Gi selector: matchLabels: type: "mysql-nfs-pv" --- apiVersion: v1 kind: PersistentVolumeClaim metadata: labels: app: wordpress name: wp-pv-claim spec: storageClassName: nfs-client accessModes: - ReadWriteOnce resources: requests: storage: 4Gi selector: matchLabels: type: "wp-nfs-pv" ```bash ? selector를 이용하여 PV를 사용하도록 설정해 주었다 ```bash Every 2.0s: kubectl get svc,pods,pv,pvc -o wide k8s-m: Thu May 26 18:10:41 2022 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR service/kubernetes ClusterIP 10.200.1.1 <none> 443/TCP 7h56m <none> service/nfs-service ClusterIP None <none> 2049/TCP,111/UDP,20048/TCP 71m role=nfs service/wordpress NodePort 10.200.1.33 <none> 80:30387/TCP 3m25s app=wordpress,tier=frontend service/wordpress-mysql ClusterIP None <none> 3306/TCP 3m25s app=wordpress,tier=mysql NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/nfs-server-rxvf7 1/1 Running 0 71m 172.16.184.9 k8s-w2 <none> <none> pod/wordpress-859f989bbb-msppd 1/1 Running 0 3m25s 172.16.158.21 k8s-w1 <none> <none> pod/wordpress-mysql-66fb7cfb68-z9vj5 1/1 Running 0 3m25s 172.16.158.20 k8s-w1 <none> <none> NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE VOLUMEMODE persistentvolume/mysql-nfs-pv 4Gi RWO Retain Bound default/mysql-pv-claim nfs-client 3m32s Filesystem persistentvolume/pvc-adc24c97-ca67-4700-b3c5-2fc51c4cce01 10Gi RWO Delete Bound default/nfs-server-pvc-fast local-path 71m Filesystem persistentvolume/wp-nfs-pv 4Gi RWO Retain Bound default/wp-pv-claim nfs-client 3m32s Filesystem NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE VOLUMEMODE persistentvolumeclaim/mysql-pv-claim Bound mysql-nfs-pv 4Gi RWO nfs-client 3m25s Filesystem persistentvolumeclaim/nfs-server-pvc-fast Bound pvc-adc24c97-ca67-4700-b3c5-2fc51c4cce01 10Gi RWO local-path 71m Filesystem persistentvolumeclaim/wp-pv-claim Bound wp-nfs-pv 4Gi RWO nfs-client 3m25s Filesystem ```bash ? 서비스가 잘 작동하는것을 확인하였다. ```bash (? |DOIK-Lab:default) root@k8s-m:~/yaml/yaml# k exec nfs-server-rxvf7 -it -- /bin/bash [root@nfs-server-rxvf7 /]# cd /exports/ [root@nfs-server-rxvf7 exports]# ll total 32 drwxr-xr-x 5 systemd-bus-proxy root 4096 May 26 09:07 1 drwxr-xr-x 5 33 33 4096 May 26 09:07 2 -rw-r--r-- 1 root root 16 May 26 07:59 index.html [root@nfs-server-rxvf7 exports]# cd 1 [root@nfs-server-rxvf7 1]# ll total 110608 -rw-rw---- 1 systemd-bus-proxy input 56 May 26 09:07 auto.cnf -rw-rw---- 1 systemd-bus-proxy input 50331648 May 26 09:07 ib_logfile0 -rw-rw---- 1 systemd-bus-proxy input 50331648 May 26 09:07 ib_logfile1 -rw-rw---- 1 systemd-bus-proxy input 12582912 May 26 09:07 ibdata1 drwx------ 2 systemd-bus-proxy input 4096 May 26 09:07 mysql drwx------ 2 systemd-bus-proxy input 4096 May 26 09:07 performance_schema drwx------ 2 systemd-bus-proxy input 4096 May 26 09:07 wordpress [root@nfs-server-rxvf7 1]# cd .. [root@nfs-server-rxvf7 exports]# cd 2 [root@nfs-server-rxvf7 2]# ll total 192 -rw-r--r-- 1 33 33 418 Sep 25 2013 index.php -rw-r--r-- 1 33 33 19935 Jan 2 2017 license.txt -rw-r--r-- 1 33 33 7413 Dec 12 2016 readme.html -rw-r--r-- 1 33 33 5447 Sep 27 2016 wp-activate.php drwxr-xr-x 9 33 33 4096 Oct 31 2017 wp-admin -rw-r--r-- 1 33 33 364 Dec 19 2015 wp-blog-header.php -rw-r--r-- 1 33 33 1627 Aug 29 2016 wp-comments-post.php -rw-r--r-- 1 33 33 2764 May 26 09:07 wp-config-sample.php -rw-r--r-- 1 33 33 3154 May 26 09:07 wp-config.php drwxr-xr-x 4 33 33 4096 Oct 31 2017 wp-content -rw-r--r-- 1 33 33 3286 May 24 2015 wp-cron.php drwxr-xr-x 18 33 33 12288 Oct 31 2017 wp-includes -rw-r--r-- 1 33 33 2422 Nov 21 2016 wp-links-opml.php -rw-r--r-- 1 33 33 3301 Oct 25 2016 wp-load.php -rw-r--r-- 1 33 33 34327 May 12 2017 wp-login.php -rw-r--r-- 1 33 33 8048 Jan 11 2017 wp-mail.php -rw-r--r-- 1 33 33 16200 Apr 6 2017 wp-settings.php -rw-r--r-- 1 33 33 29924 Jan 24 2017 wp-signup.php -rw-r--r-- 1 33 33 4513 Oct 14 2016 wp-trackback.php -rw-r--r-- 1 33 33 3065 Aug 31 2016 xmlrpc.php ```bash ? 목적이었던 NFS도 정상적으로 작동한다. ```bash (? |DOIK-Lab:default) root@k8s-m:~/yaml# k scale deployment wordpress --replicas=3 (? |DOIK-Lab:default) root@k8s-m:~/yaml# k get pod NAME READY STATUS RESTARTS AGE nfs-server-rxvf7 1/1 Running 0 77m wordpress-859f989bbb-8r5zh 1/1 Running 0 47s wordpress-859f989bbb-msppd 1/1 Running 0 8m38s wordpress-859f989bbb-xhbs9 1/1 Running 0 47s wordpress-mysql-66fb7cfb68-z9vj5 1/1 Running 0 8m38s (? |DOIK-Lab:default) root@k8s-m:~/yaml# k get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE mysql-nfs-pv 4Gi RWO Retain Bound default/mysql-pv-claim nfs-client 9m6s pvc-adc24c97-ca67-4700-b3c5-2fc51c4cce01 10Gi RWO Delete Bound default/nfs-server-pvc-fast local-path 77m wp-nfs-pv 4Gi RWO Retain Bound default/wp-pv-claim nfs-client 9m6s (? |DOIK-Lab:default) root@k8s-m:~/yaml# k get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE mysql-pv-claim Bound mysql-nfs-pv 4Gi RWO nfs-client 9m2s nfs-server-pvc-fast Bound pvc-adc24c97-ca67-4700-b3c5-2fc51c4cce01 10Gi RWO local-path 77m wp-pv-claim Bound wp-nfs-pv 4Gi RWO nfs-client 9m2s ```bash ? 볼륨도 잘공유하여 프로비저닝 된것을 확인할수 있다. ㅜㅜ