개인코딩개발공장

## clusterIP service/ 개념 & test # deployment를 쓰는이유? 고가용성! 이렇게 deployment로 생성된 세개의 nginx pod들이 있다고 가정하자. 일단 우리가 deployment컨트롤러로 동일한 pod 세 개를 운영하는 목적은 뭐였니? 고가용성을 보장하 jacobowl.tistory.com 이전 포스팅에서 실제로 서비스를 만들어보면서 만든게 clusterIP타입 서비스이다. 서비스를 만들때 type을 딱히 안정해주면 알아서 clusterIP타입 서비스를 만들어준다. 떄문에 자세한 설명은 생략을 하려한다. 부족한부분을 몇개 추가하자면.. # yaml형식 + clusterIP 커스텀 apiVersion: v1 kind: Service metadata: name: my-..

# deployment를 쓰는이유? 고가용성!이렇게 deployment로 생성된 세개의 nginx pod들이 있다고 가정하자.일단 우리가 deployment컨트롤러로 동일한 pod 세 개를 운영하는 목적은 뭐였니?고가용성을 보장하기 위해서다. 고가용성이란 만약 노드 하나가 죽거나 한가지 pod가 죽거나 등등 뭐 ㅈ같은 일이 생겼을 경우 서비스가 죽게 될 것인데, 이거를 대비하려고 deployment컨트롤러로 동일한 pod들을 replicas 설정을 통해 만들어줬다.  # 헐이렇게 세개의 동일한 pod들을 배포해줬고 deployment컨트롤러가 가용성을 보장해준다. 근데 이 세개의 pod들안에서 nginx컨테이너가 띄운 웹사이트들은 다 똑같지만 접속하려면 서로 다른 아이피로 접속을 해야한다. 그러면 의미가..

# 개념 job을 일정시각마다 실행하게 하는거다. 예를들어 매일 정각에 한번씩 job을 실행하게 하는거거나.. 뭐 이런거다. 매일 로그를 백업한다거나 점검 프로세스를 job으로 넣어두고 하는데 쓰면 좋을것 같다. # yaml양식 apiVersion: batch/v1 kind: CronJob metadata: name: hello spec: schedule: "* * * * *" jobTemplate: spec: template: spec: containers: - name: hello image: busybox:1.28 imagePullPolicy: IfNotPresent command: - /bin/sh - -c - date; echo Hello from the Kubernetes cluster res..

# 기본적인 pod 동작원리 kubectl run testpod --image centos:7 --command sleep5 pod의 기본적인 특징이, pod안에 컨테이너가 제대로 안되면 계속 재시작을 시킴 liveness container는 이런걸 커스텀 할 수 있는것 같고.. 기본적으로는 pod안에 컨테이너가 정상이아니면 계속 살려냄. kubectl get pods -o wide --watch containerCreating으로 컨테이너가 생겨나고, running하다가 5초후에 sleep 5 커맨드가 끝나고 멈춰버린다. 안에있던 코드는 정상적으로 종료된거다. 때문에 completed가 뜨고 실행중인 컨테이너가 0/1로 바뀌는데, 이제 동작하는 컨테이너가 없으니 다시 이 컨테이너를 살려내고 다시 5초후..

## 마스터노드 - 워커노드 커넥션 연동&해제하기 # 마스터 노드 - 워커 노드를 연결을 끊는 방법부터 알아보자. master node에서 먼저 node를 제거해줘야 한다. kubectl get nodes 난 현재 worker1, worker2 이렇게 두 워커 노드가 있다. 여기서 worker1 node를 삭제해보겠다. 삭제하기전에 node1에서 작동중인 pod가 있는지를 체크하고 삭제하자. kubectl delete nodes worker1 삭제 후에 해당 워커노드 vm으로 가서, kubeadm reset 명령어를 치면 master node와의 행복한 기억들을 모두 지워준다. 중간에 y까지 치고 동의하면, 뭐가 뜨는데 잘된건진 모르곘다. 이후에 join을 쳤을때 안되면 잘안된거다. # master no..

하씨발 이틀동안 적어놓은 포스팅 임시저장 싹다 사라져서 다시 적어야 한다 ㅈ같은씨발 # replicaSet replicaSet은 replication controller와 거의 비슷하다고 봐도 될것같다. 그냥 파드 수를 보장하는기능은 가능한데 조금더 업그레이드 된 기능은 더욱 풍부한 라벨셀렉터를 지원한다는 점이다. 단순히 replication controller는 라벨을 AND연산으로 관리한다고 하면, replica Set의 셀렉터는 OR연산등 여러가지를 지원한다. # replication controller와 replicaSet의 yaml형식 비교 replication controller와 뭐 다 비슷하게 생겼지만 셀렉터가 다르다. 얘는 matchLabels으로 한번 더 들어간다. 그리고 그 이후는 키..

# 개념 이전에 pod 실행 순서를 설명하면서 써먹었던 그림인데, 파드가 생성되는건 먼저 API에 명령어로 요청을 보내고 etcd에서 노드 정보들을 가져와서 scheduler가 파드를 노드에 알아서 분배해주는 과정으로 pod가 생성된다고 했다. 근데 그 전에도 있던 controller도 포함했는데 설명에 없었다. controller는 pod의 갯수를 보장해주는? 그런거라고 볼 수있다. aws의 auto scaling?에서의 수평적 확산 개념과 연동지어서 생각 할 수도 있을듯..? 파드의 갯수를 보장해준다. 이걸 마스터 노드의 controller가 보장을 해주게 된다. # 컨트롤러의 종류 이렇게 일곱가지의 컨트롤러 종류가 있는데, cronjob - job은 짝꿍, deployment와 replicaset은..

## static pod 만들기 보통 마스터노드에서 컨테이너를 만들면 저렇게 api서버를 거쳐서 pod가 생성된다. 하지만 static pod는 워커 노드 자체에서 kubelet이 직접 pod를 만든다는 것이다. 즉 이 pod는 kublet데몬에 의해 관리되는 파드이다. 마스터노드에서 확인가능 # 직접 만들어보자. 일단 워커 노드중 아무거나 하나 가서 해당 파일 내용을 보자. cat /var/lib/kubelet/config.yaml 요기에 static pod path가 있음 static pod path는 /etc/kubernetes/manifests 라고 한다. 직접 이 경로에 가보자. cd /etc/kubernetes/manifests https://kubernetes.io/docs/concepts/..

# 기본개념 pod안에있는 컨테이너가 자체적으로 자가검진을 해서 원하는 기능이 동작안할경우 컨테이너를 재시작 해주는 기능이다. 예를들어 웹서버를 띄웠는데 80포트로 연결했는데 응답이 500번대가 뜨면 컨테이너를 재시작 해주는 거임. # 종류 - httpGet 웹사이트에 80번포트로 게쏙 get요청보내고 응답하는지 확인함. 200응답안주면 컨테이너 재시작해주는거다. - tcpSocket tcp연결을 지정한 포트로 시도하고 안되면 컨테이너 재시작 - exec 커맨드 게속 날리고 종료코드가 0이아니면 컨테이너 재시작 걍 커맨드 날렸는데 응답이 없으면 재시작하는 그런 기능이다. # http로 예를 들어볼까? apiVersion: v1 kind: Pod metadata: name: test-pod spec: co..

# 파드 생성 순서 우리가 마스터 노드에서 kubectl 명령어를 치면 먼저 api 가 문법 맞는지 체크부터한다. 그다음, etcd정보(node정보들)를 가져와서 스케줄러에 보낸다. etcd가 노드 관리하는듯? 스케줄러는 어느 노드에 pod를 띄울지 정하는애니까 이런 정보를 받아야 노드를 정할 수 있을것이다. 스케줄러는 파드를 어느 node에 띄울지 선택하고 띄워준다. 띄워주고 나서는 running상태가 된다. 배치 받고나서는 running상태 or fail상태 뭐 단순하게 배웠는데, 실제 환경에서 테스트를 해보면.. 현재 위아래로 세션을 두개 띄웠고 위 세션에서는 kubectl get pods -o wide --watch 명령어로 파드생성을 실시간으로 모니터링하고 있다. 이제 아래 세션에서 새로운 파드..