반응형

kubectl drain 노드명

- drain 명령어를 사용하게 되면 해당 노드의 pod 를 다른 노드로 옮긴다.
- 실제로는 pod 를 옮기는게 아니라 다른 노드에 재 생성한다.
- 데몬셋을 무시하고 진행할 경우에는 --ignore-daemonsets 옵션을 사용한다.

아래와 같이 myserver-002와 myserver-003 에 pod 가 각각 deploy 되어있다.

root@myserver-001:~# kubectl get po -o wide
NAME                            READY   STATUS    RESTARTS   AGE     IP          NODE           NOMINATED NODE   READINESS GATES
rollout-nginx-74695fdcd-5trw5   1/1     Running   0          3m55s   10.32.0.2   myserver-002   <none>           <none>
rollout-nginx-74695fdcd-jkw2d   1/1     Running   0          3m55s   10.47.0.2   myserver-003   <none>           <none>
rollout-nginx-74695fdcd-tp75z   1/1     Running   0          3m55s   10.47.0.1   myserver-003   <none>           <none>

이 상황에서 myserver-003 을 drain 을 시켜보면 다음과 같이 변경된다.

root@myserver-001:~# kubectl get nodes
NAME           STATUS                     ROLES                  AGE     VERSION
myserver-001   Ready                      control-plane,master   2d8h    v1.22.3
myserver-002   Ready                      <none>                 2d8h    v1.22.3
myserver-003   Ready,SchedulingDisabled   <none>                 4h23m   v1.22.3

 

root@myserver-001:~# kubectl get po -o wide
NAME                            READY   STATUS    RESTARTS   AGE     IP          NODE           NOMINATED NODE   READINESS GATES
rollout-nginx-74695fdcd-5trw5   1/1     Running   0          4m45s   10.32.0.2   myserver-002   <none>           <none>
rollout-nginx-74695fdcd-8c55f   1/1     Running   0          11s     10.32.0.3   myserver-002   <none>           <none>
rollout-nginx-74695fdcd-h6txz   1/1     Running   0          11s     10.32.0.4   myserver-002   <none>           <none>

기존에 있던 rollout-nginx-74695fdcd-5trw5 파드를 제외하고 나머지 pod 는 이름을 보면 새로 만들어진것이다. Age 도 11s 로 나온다. 따라서 위에서 말한것처럼 drain 을 했을 경우 pod 를 옮기는게 아니라 삭제하고 새로 만들게 된다. 

 

728x90
반응형
반응형

static pod 에 대해서 알아보다가 몇가지 기억할 만한 것들을 적어본다.

- master node 의  /etc/kubernetes/manifests 하위에는 yaml 파일들이 있는데 이 yaml 파일들은 마스터 노드가 실행시에 자동으로 생성되는 static pod 들이다. 보통 etcd, api-server등이 있다.

- node에 생성된 static pod 를 지우기 위해서는 해당 노드에 가서 지워야 한다. 지우기 위해서는 노드 안에 있는 kubelet의 config 파일(/var/lib/kubelet/config.yaml) 에 있는 staticPodPath 값을 찾아서 path 위치에 있는 yaml 파일을 지워야 한다. kubectl delete pod 로 지우면 다시 생성된다.

- 조회는 가능하지만 edit 는 불가능 하다.

 

728x90
반응형
반응형

Pod

개념

쿠버네티스에서 실제로 컨테이너를 묶어서 관리하는 단위

설정

apiVersion: v1
kind: Pod
metadata:  
  name: simple-pod          (Pod 이름)
  labels: 
    app: simple-pod         (오브젝트를 식별하는 레이블)
spec:
  containers:
  - name: simple-pod        (컨테이너 이름)
    image: ~~~              (컨네이너에서 사용할 이미지)
    ports:
    - containerPort: 8080

Pod 생명주기

Pending -> Running

Successed

Failed

Unknown

컨테이너 진단

  • ivenessProbe

    컨테이너가 실행됐는지 확인

    실패시 컨테이너를 종료시키고 재시작 정책에 따라서 재시작

  • readinessProbe

    컨테이너 실행된 후 실제로 서비스 요청에 응답할 수 있는지 진단

    컨테이너가 실제로 트래픽을 받을 준비가 되었음을 확인할 수 있어 유용함

초기화 컨테이너(Init Container)

  • 앱 컨테이너가 실행 되기 전 Pod 를 초기화 한다.

  • 여러개 구성 가능하며 실행 순서는 템플릿에 명시한 순서를 따른다.

  • 실패시 성공할때 까지 재시작한다.

  • readinessProbe 를 지원하지 않는다 - Pod 가 준비되기 전에 실행후 종료되기 때문

  • 설정

    .spec.initContainers[] 의 하위 필드

      apiVersion: v1
      kind: Pod
      metadata:  
          name: simple-pod
          labels: 
              app: simple-pod
      spec:
          initContainers:
          - name: 
            image:
            command        

파드 인프라 컨테이너

pause 컨테이너

  • Pod Infrastructure Container (파드 인프라 컨테이너)
  • 모든 Pod 에서 항상 실행된다
  • 다른 컨테이너의 부모 역할을 한다
  • Pod 안 다른 컨테이너들은 pause 컨테이너가 제공하는 네트워크를 사용
  • pause 컨테이너 재시작시 Pod 안 모든 컨테이너 재시작됨
    c34dff11289b        arisu1000/simple-container-app   "./simple-container-…"   41 minutes ago      Up 41 minutes                           k8s_simple-pod_simple-pod_default_112e5cb1-101b-4cb6-a591-c83c6171cce5_0
    67c790777792        k8s.gcr.io/pause:3.2             "/pause"                 41 minutes ago      Up 41 minutes                           k8s_POD_simple-pod_default_112e5cb1-101b-4cb6-a591-c83c6171cce5_0

스태틱 Pod

  • kube-apiserver 를 통하지 않고 kubelet 이 직접 실행하는 Pod
  • 조회는 가능하지만 명령 실행은 불가능(직접 edit 등 불가능)
  • 시스템 파드 실행용도로 많이 사용
  • 스태틱 Pod 경로 : /etc/kubernetes/manifests

자원 할당

  • requests 최소자원, limits 최대자원

    .spec.containers[].resources.limits.cpu

    .spec.containers[].resources.limits.memory

    .spec.containers[].resources.requests.cpu

    .spec.containers[].resources.requests.memory

  • requests 만 설정했을 경우 해당 값보다 더 많이 사용할 수 있기 때문에 limits 설정을 해야 Out of Memory 를 피할수 있다.

  • Memory : Exa, Peta, Tera, Giga, Mega, Kilo (맨 첫글자 사용)

  • CPU : 소수점일 경우 1개 코어에 해당하는 연산능력을 의미( 0.1 일경우 1코어의 10%만 활용)

Pod 의 환경 변수

.spec.conainers[].env[] 하위 필드

  • name
  • value
  • valueFrom
  • fieldRef
  • fieldPath
  • resourceFieldRef
  • containerName
  • resource

출처 : 쿠버네티스 입문 - 90가지 예제로 배우는 컨테이너 관리자 자동화 표준 (동양북스)

728x90
반응형
반응형

Cluster

- Master, Node 2가지 타입의 리소스가 존재한다.

- Master : cluster를 관리한다. 

- Node : Worker Machine 으로 제공되는 VM 또는 물리적 컴퓨터이다. 

            각각의 Node 는 Node 를 관리하고 Kubernetes master와 커뮤니케이션을 할수 있는 Kubelet 이라는 agent 를 가지고 있다. 

            Node 는 master 가 노출시켜놓은 Kubernetes API 를 사용해서 통신을 한다. 





https://kubernetes.io/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/

Pod

- Deployment 를 생성하게 되면 Deployment는 Pod 를 생성하고 그 안에 Container 를 넣는다. 

- Pod 는 1개 이상의 어플리케이션 컨테이너와 그 컨테이너들이 공유하는 리소스의 그룹이다. 

- 공유 리소스는 volume, clusterIP 가 있다. 

- Pod 안에 있는 Container 들은 IP 와 port 를 공유한다. 

- Pod 는 Unique IP address 를 가지고 있다.


https://kubernetes.io/docs/tutorials/kubernetes-basics/explore/explore-intro/



Service

- Pod 의 논리적 집합과  그것을 접근 할수 있는 정책을 정의 해준다. 

- Service 가 설정하는 Pod 의 논리적 집합은 LabelSelector 로 정의 한다. 

- 다음과 같은 type 이 존재한다. 


 type

 내용 

 ClusterIP 

 default 이다. cluster 의 internal IP 만 노출 시키기 때문에 cluster 내부에서만 접근 가능하다. 

 NodePort 

 각각의 NodeIP 에 서비스를 노출시킨다. NodePort 서비스가 라우팅 할 ClusterIP 서비스가 자동으로 생성된다. 클러스터 외부에서 <NodeIP>:<NodePort> 로 접근 가능하다. 

 LoadBalancer 

 external IP 를 생성하여 클러스터 외부에서 접근 가능하게 해준다. ClusterIP 와 NodePort는 자동으로 생성된다.




https://kubernetes.io/docs/tutorials/kubernetes-basics/expose/expose-intro/

728x90
반응형

+ Recent posts