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> 먼저 예제를 보여준다. NodeLess EKS 컨셉의 기반이다. nginx-pod / aws-node-h5z8d / kube-proxy-z8qlj 는 카펜터가 만든 노드위에 올라가 있다. ...

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 ...

이글은 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"] . 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 read 명령어를 이용하여 스크립트에 변수를 부여하고 입력받은 변수를 이용하여 aws configure 를 설정하고, kops 명령어로 k8s 클러스터를 프로비저닝한다. ...

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 ? ...