쿠버네티스 서비스란

• 쿠버네티스 네트워크이다.
• api 서비스이다.
• service는 쿠버네티스에 동일한 레이블을 가진 파드들을 하나의 ip로 묶어서 관리를 요청한다.
  • 쿠버네티스는 동일한 레이블을 갖고 있는 pod를 하나의 virtual ip로 묶는다.
  • virtual ip는 로드밸런스 ip가 된다.
  • 즉 이러한것이 만들어지도록 요청하는것이 쿠버네티스 서비스이다.

서바스 타입

• cluster ip

  • 기본 cluspte의 역할로 로드밸런서 ip를 만듦

  • 예제

    kind: Service
    metadata:
    name: ${name}
    spec:
    type: ClusterIP
    clusterIP: ${ip}
    selector:
    app: ${app}
    ports:
    - protocol: TCP
    port: ${virtual ip port}
    targetPort: ${pod port}

• node port

  • cluster ip 기능에 추가로 포트까지 지원함

  • 즉 로드밸런서 ip에 포트까지 붙일 수 있도록 지원

  • 외부에서 들어올수 있는 노드의 포트가 열림

  • 워커 노드가 1,2,3이 있고 각각에 pod가 하나씩 있을때

    • 2번 워커노드의 열린 포트로 클라이언트가 요청을 하면

    • 해당 워커노드가 로드밸런싱을 하여 1,2,3번의 내부 pod 중 하나로 요청을 보내준다.

      kind: Service
      metadata:
      name: ${name}
      spec:
      type: NodePort
      clusterIP: ${ip}
      selector:
      app: ${app}
      ports:
      - protocol: TCP
      port: ${virtual ip port}
      targetPort: ${pod port}
      nodePort : ${node port}

• loadbalaner

  • 클러스터 Ip 에 추가로 실제 로드밸런서 장비의 포트와 virtual 로드밸런서 포트를 연결
  • 물리 로드밸런서가 node port 로 요청을 전달

• external Name

  • 네이밍 서비스를 만든다.
  • dns 서비스를 클러스터 내부안에서 지원해준다.
  • 보통 외부 서버로 요청을 연결하는 경우에 사용한다.

• 확인해보기

  • ip : lb ip
  • endpoints : 실제 연결되는 ip

• kubectl describe svc clusterip-service

• 서바스 중단

• kubectl delete service -all

헤드리스 서비스

• clusterip가 없는 서비스로 단일 진입점이 따로 필요 없을때 사용됨
• 하지만 endpoint로는 묶어줌
• pod들의 endpoint를 dns resolving service 쓸 수 있도록 함
• 즉 pod하나하나에 대한 dns를 core dns에 등록하여 각각 쓸 수 있음

  apiVersion: v1
  kind: Service
  metadata:
  name: ${name}
  spec:
  type: ClusterIP
  clusterIP: None #이부분으로 사실상 헤드리스 서비스 명시!

  ###kube-procy
• 쿠버네티스의 백엔드를 구현
• 즉 clusert ip를 쓰면, 실제로는 실제 각 노드별로 iptables가 있어서, 이게 요청을 받으면 각 내부 pod중 한개로 전달하는 방식이다.
• 그래서 실제 노드에서 iptables확인해보면 iptables가 찍힌다.
• node port를 쓰는 경우 해당 포트를 리슨함

• 여러대의 control plane으로 구성
• 세대중에 한대가 다운되더라도 운영 가능(고 가용성)
• 보통 홀수로 이용
• 로드밸런서가 control plane을 선택하여 요청을 보냄(즉 worker노드가 마스터로 무언갈 보낼때 로드밸런서를 통해 감)
• 여러대의 conrol plane 간에는 동기회를 진행
• nginx로 로드밸런싱을 하는경우 upstream stream_backend를 이용

job

• job controller
  • 보통 다른 컨트롤러들은 pod를 죽이면 계속 수행됨
  • 하지만 pod가 기능 수행을 완료하면 굳이 계속 수행될 필요가 없을 수 있음
  • 기능이 수행되면 상태가 completed가 된다. 따로 지우지는 않는다.
  • pod가 삭제되면 내부 로그를 알 수 없기 때문에 따로 지우지는 않는다.
  • restartPolicy 설정을 통해 실패시 사용할 정책을 지정할 수있다.
  • backoffLimit으로 restartPolicy 보조
  • replicas대신 completions을 사용, 다만 컨테이너 수가 아니라 실행 횟수임
  • 유지갯수는 parallelism으로 설정

cronjob

• job을 제어하여 작업예약을 지원한다
• crontab이랑 비슷함
• 사실상 job definition에 schedule만 추가한다

• pod의 상태를 유지해주는 컨트롤러

  • pod의 이름 보장
    • 기존에 다른 컨트롤러를 쓰면 ${pod_name}-${hash} 로 생성됨
    • StatefulSet은 이와 다르게 이름을 보장함
    • ${pod_name}-1,${pod_name}-2,${pod_name}-3 이렇게 만들 수 있음
    • 만약 2가 삭제되면 2를 생성함, 즉 이름의 형태는 전체적으로 보장이 된다.

• scale statefulset 으로 replicas를 조정할 수 있다.

  kubectl scale statefulset ${} --replicas=${}

• scale out을 하는경우 0,1,2,3 이면 3,2,1,0 순으로 삭제된다.

• rollingupdate 가능

  kubectl edit statefulsets.apps ${}

• roolout 가능

  kubectl rollout undo statefulset ${}

• 노드에서 pod가 한개씩 실행되도록 보장

• 노드에서 pod가 하나씩 실행되는 경우는 각 노드의 물리장비를 모니터링하는 경우등에 사용됨

• daemonset은 replicas를 따로 지정하지 않아도 자동으로 node당 하나씩 수행된다.

• daemonset은 rolling update 가능하다.

• daemonset 로그 확인

  kubectl get daemonsets.apps

• daemonset 수정

  • 하나를 완료하고 완료되면 다른 pod를 완료하고 ... 이런식으로 롤링 업데이트

    kubectl edit daemonsets.apps ${pod-name}

• 롤백

  kubectl rollout undo daemonset ${pod}

• Replication Controller 랑 비슷함

• 차이는 풍부한 Selector를 지원해줌

  • matchLabels, matchExpressions 를 쓸 수 있음
  • matchExpressions 을 통해 or 조건, not null 조건등을 쓸 수 있음

• controller 없애주기

kubectl delete rs rs-nginx --cascade=false

• label은 서로 다른 pod간 절떄 겹치지 않게 한다. 겹치면 있다고 인식하여 replicas의 갯수가 덜 생성된다.

• Pod의 갯수를 보장

Replication Controller

• 요구하는 pod의 갯수를 보장

• replicas, selector,template으로 구성됨(replicationController 는 이 세개가 필요하지 않음)

• selector를 식별자로 하여, worker노드에 띄워진 것들의 갯수가 replicas랑 동일한지 확인하다 잘못된게 있으면 template 대로 생성

• selector의 이름은 pod가 다른경우 겹치지 않게 한다

kind:ReplicationController

spec:  
  replicas: ${val}  
  selector:  
      ${val}: ${val}  
  template:  
      ${val}

• replicationController확인하기

  kubectl get replicationcontrollers
  kubectl get rc

• 수정하기

  kubectl edit rc ${pod}
  kubectl scale rc ${pod_name} --replicas=${num}

• 롤링 업데이트 : 서비스 중에 중단하지 않고 업데이트

  • 만약 버전을 바꾸는 롤링업데이트를 하려면 수정을 한 후 delete pod하면 다시 살아나는것에 반영됨

static pod

• control-plane(master)의 api를 실행하지 않고 pod를 만든다
• worker노드의 kubelet 의 특정 디렉터리에 yaml을 만들면 자동으로 pod가 생성되고, yaml이 사라지만 pod가 사라짐
• 즉 kubelet 데몬을 통해 pod가 생성됨
• 보통 /etc/kubernetes/manifests 여기 위치가 worker노드의 static pod 생성 파일 저장 위치
• 마스터 노드의 static pod는 다음과 같다
• controlplane $ pwd /etc/kubernetes/manifests controlplane $ ls etcd.yaml kube-controller-manager.yaml kube-apiserver.yaml kube-scheduler.yaml

pod 리소스

• 보통 pod를 만들때 따로 리소스를 제한하지 않으면 모든 리소스를 다쓸 수 있다.

• 또한 pod를 생성할때 클라이언트가 원하는 자원이상이 남는 노드에 만들 수 있다.

  • request는 scheduler가 결정, 즉 이것 이상으로 리소스가 있는 노드에 pod를 만든다
  • limit은 리소스가 초과되면 자동으로 restart 된다.
  • limit만 쓰면 동일한 값으로 requests가 복제가 되어 들어감
  • request만 쓰면 limit은 따로 안들어감
  • 만약 requests를 너무 크게 잡아서, 장비가 감당하지 못하면 pod가 생성되지 않고 pending이 된다,

• 컨테이너별로 리소스 설정

• yaml 예제

    resources:
      requests:
        memory: 1
        cpu: 1Gi
      limits:
        memory: 3
        cpu: 3Gi

pod 변수

• pod 생성 yaml에서 컨테이너의 환경변수를 변경하고 설정할 수 있다.
• 이미 컨테이너에 환경설정이 되어있어도 이를 덮어써서 변경할 수 있다.
• ex

    env:
    - name: ${name}
      value: ${value}

pod의 세가지 패턴

• sidecar : 한 pod에서는 로그를 만들고 다른 pod에서는 이를 분석, 즉 두개가 함께 동작
• adapter : 외부에 모니터가 있고, 어뎁터 pod가 외부에 모니터링 정보를 받고, web pod가 모니터링 정보를 받아 시각화하여 외부에 제공
• ambassador : 웹서버pod에 고객이 웹서버를 이용하면 이에 대한 정보를 ambassador pod가 lb 역할로 이를 받아 외부에 제공

init container란?

• 메인컨테이너를 실행하는데 필요한 환경세팅

• init 컨테이너가 성공해야 main 컨테이너가 실행됨

  • 또는 컨테이너의 사전 점검

  • 하기와 같이 설정 가능

infra container (pause conatiner)

• pod를 만들면 자동으로 하나씩 생성되는 컨테이너
• pod에 대한 ip나 인프라등을 관리하고 생성한다.

self-healing

• 정상적인 컨테이너로 어플리케이션 서비스를 하는것을 보장

• 정상적이지 않으면 컨테이너를 restart한다

• 설정 방법

  • spec에 linessProbe 추가

• httpGet

  livenessProbe:
  httpGet:
    path:/
    port:80

• tcpSocket

  livenessProbe:
  tcpSocket:
    port:8080

• exec

  livenessProbe:
  exec:
    command:
    - ${명령어}