Ingress

개념

• 클러스터 외부에서 안으로 접근하는 요청들을 어떻게 처리할지 정의해둔 규칙
• 인그레스는 규칙들의 모음이며 실제로는 인그레스 컨트롤러가 동작시킨다.

설정

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foos1
        pathType: Prefix
        backend:
          service:
            name: s1
            port:
              number: 80
      - path: /bars2
        pathType: Prefix
        backend:
          service:
            name: s2
            port:
              number: 80
  - host: bar.foo.com      
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:      
          service:
            name: s2
            port:
              number: 80  

• annotation 은 인그레스 컨트롤러마다 다르다. (https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/)

  ingress version 차이

• 1.18

  apiVersion: networking.k8s.io/v1beta1
  kind: Ingress
  metadata:
    name: test-ingress
    annotations:
      nginx.ingress.kubernetes.io/rewrite-target: /
  spec:
    rules:
    - http:
        paths:
        - path: /testpath
          pathType: Prefix
          backend:
            serviceName: test
            servicePort: 80

• 1.19

  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: minimal-ingress
    annotations:
      nginx.ingress.kubernetes.io/rewrite-target: /
  spec:
    rules:
    - http:
        paths:
        - path: /testpath
          pathType: Prefix
          backend:
            service:
              name: test
              port:
                number: 80

SSL 설정

• tls 생성

  openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=kube-book.com"
  Can't load /root/.rnd into RNG
  140377540018624:error:2406F079:random number generator:RAND_load_file:Cannot open file:../crypto/rand/randfile.c:88:Filename=/root/.rnd
  Generating a RSA private key
  ........................+++++
  ........+++++
  writing new private key to 'tls.key'  

• tls secret 생성

  kubectl create secret tls kube-book-secret --key tls.key --cert tls.crt  

• .spec.tls 설정

  spec:
  tls:
  - hosts:
    - kube-boo.com
    secretName: kube-book-secret

무중단 배포시 주의 할점

• maxSurge 와 maxUnavailable 설정
  • maxSurge : 디플로이먼트에 기본 pod 개수에 여분의 파드를 몇개 추가 할수 있는지 설정
  • maxUnavailable : 디플로이먼트 업데이트시 사용할수 없는 파드 개수
• readinessProbe 확인
  • 실제 서비스 요청 처리할 준비가 되었는지 진단
  • 설정 불가능할 경우 .spec.minReadySeconds 설정. 해당 설정 기간동은 트래픽을 받지 않지만 그 이후에는 받는다.
• graceful 종료
  • 기존 받은 요청만 처리하고 새 요청은 받지 않는다
  • 설정 불가능 할 경우 hock 을 설정한다.

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

Service

개념

• 동적으로 변하는 Pod 들을 고정적으로 접근할 때 사용한다.
• 서비스는 주로 L4영역에서 통신할 때 사용한다.

서비스 타입

• ClusterIP
  • default, 클러스터 내부에서만 사용가능
• NodePort 모
  • 모든 노드에 지정된 포트를 할당함.
  • 외부에서 접근 가능
• LoadBalancer
  • EXTERNAL-IP 생성
  • 외부에서 Pod 접근 가능 할수 있게 해줌
• ExternalName
  • 서비스를 .spec.externalName 필드에 설정한 값과 연결한다.
  • 클러스터 안에서 외부에 접근할 때 주로 사용한다.

서비스 사용

• 설정

  apiVersion: v1
  kind: Service
  metadata:
    name: my-service
  spec:
    type: ClusterIP
    selector:
      app: MyApp
    ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

  • .spec.clusterIP 값을 None 로 설정하면 IP 가 없는 서비스 생성 가능

kube-proxy

• userspace 모드
  • Pod 연결 요청시 실패할 경우 다른 Pod에 연결을 재시도함.
• iptables 모드
  • 클라이언트 요청을 iptables 를 거쳐 Pod 로 직접 전달
  • Pod 연결 요청시 실패할 경우 재시도 안함
• IPVS 모드

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

Controller

개념

Pod 를 관리하는 역학을 한다.

Replicatoin Controller(레플리케이션 컨트롤러), ReplicaSet(레플리카 셋)

Replication Contller

• 초기부터 있었던 기본적인 컨트롤러
• 명시한 Pod 개수만큼 유지하도록 해준다.
• 현재는 ReplcaSet 을 쓴다.

ReplicaSet

• 레플리케이션 컨트롤러의 발전형.

• 레플리케이션 컬트롤러와 차이점은 집합기반 셀렉터를 지원 한다. (in, notin, exists)

• rolling-update 옵션 사용불가

• 설정

  apiVersion: v1
  kind: ReplicaSet
  metadata:
    name: nginx-replicaset
  spec:
    template:
      metadata:
        name: nginx-replicaset
        labels:
          app: nginx-replicaset
      spec:
        containers:
        - name: nginx-replicaset
          image: nginx
          ports:
          - containePort: 80
    replicas: 3
    selector: 
      matchLabels: 
        app: nginx-replicase

  • .spec.template.metadata.labels 의 설정과 spec.selector.matchLabels의 설정이 같아야 한다.
  • selector 설정이 없을 경우 .spec.template.metadata.labels 를 따라간다.

• 레플리카셋 삭제시 --cascade=false 옵션을 하면 레플리카셋만 삭제 가능하다. (Pod 삭제안됨)

Deployment(디플로이먼트)

• Stateless 앱 배포시 사용하는 기본적인 컨트롤러

• 레플리카셋을 관리한다.

• 설정

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: nginx-deployment
    labels:
      app: nginx-deployment
  spec:
    replicas: 3
    selector:
      matchLabels:
        app: nginx-deployment
    template:
      metadata:
        name: nginx-deployment
        labels:
          app: nginx-deployment
      spec:
        containers:
        - name: nginx-deployment
          image: nginx
          ports:
          - containerPort: 80

• 생성시 Deployemnt, ReplicaSet, Pod 가 생성된다.

• 설정정보 Update 방법

  • kubectl set
  • kubectl edit
  • yaml 파일 수정후 apply

• revsion

  • kubectl rollout history deployment 이름
  • kubectl rollout undo deploy (이전 revision 으로 롤백)
  • kubectl rollout undo deploy 이름 --to-revision=숫자 (특정 revision 으로 롤백)

• Pod 개수 조정

  • kubectl scale deploy 이름 --replicas=숫자

• 배포 정지, 재개, 재시작

  • kubectl rollout pause deployment/이름
  • kubectl rollout resume deployment/이름

Daemonset (데몬셋)

• 클러스터 전체 노드에 특정 파드를 실행할 때 사용하는 컨트롤러

• 클러스터 전체에 항상 실행시켜두어야 하는 파드에 사용

• 설정

  apiVersion: apps/v1
  kind: DaemonSet
  metadata:
    name: fluentd-elasticsearch
    namespace: kube-system
    labels:
      k8s-app: fluentd-logging
  spec:
    selector:
      matchLabels:
        name: fluentd-elasticsearch
    updateStrategy:
      type: RollingUpdate
    template:
      metadata: 
        labels:
          name: fluentd-elasticsearch
      spec:
        containers:
        - name: fluentd-elasticsearch
          image: fluent/fluentd-kubernetes-daemonset:elasticsearch
          env:
          - name: testenv
            value: value
          resources:
            limits:
              memory: 200Mi
            requests:
              cpu: 100m
              memory: 200Mi

  • .spec.updateStrategy.type : 다음 두가지중 선택
    • OnDelete : 파드가 삭제되었을때 반영된다.
    • RollingUpdate : 기본값 (1.5 이하에서는 OnDelete 가 기본값)
      • 템플릿 변경시 바로 반영
      • 모든 파드가 한꺼번에 반영되는건 아니고 .spec.updateStrategy.rollingUpdate.maxUnavailable 필드와 .spec.minReadySeconds 필드를 추가로 설정해 한번에 교체하는 파드를 조정한다.

StatefulSets (스테이트풀 셋)

• 상태가 있는 파드들을 관리하는 컨트롤러
• 생성될때 Pod 에 UUID 가 붙는게 아니라 숫자(0,1,2..)가 붙는다.
• 삭제될때에는 숫자가 큰것부터 삭제가 된다. (업데이트시에는 Pod를 삭제하고 다시 생성하기 때문에 마찬가지로 숫자가 큰것부터 수정된다.)

Job (잡)

• 실행된후 종료해야 하는 성격의 작업을 실행할때 사용하는 컨트롤러

• 설정

  apiVersion: batch/v1
  kind: Job
  metadata:
    name: pi
  spec:
    template:
      spec:
        containers:
        - name: pi
          image: perl
          command: []
        restartPolicy: Naver
    backoffLimit: 4

  • .spec.completions : 정상적으로 실행 종료 되어야 하는 파드 개수
  • .spec.parallelism : 동시에 실행 가능한 파드 개수
  • .spec.restartPolicy : 재시작 정책을 설정한다.

크론잡

• job 을 시간 기준으로 관리한다. 주기적으로 반복이 가능하다.

• 설정

  apiVersion: batch/v1beta1
  kind: CronJob
  metadata:
    name: hello
  spec:
    schedule: "*/1 * * * *"
    jobTemplate:
      spec:
        template:
          spec:
              containers:
              - name: hello
                image: busybox
                args:
                - /bin/sh
                - -c
                - date; echo Hello form the k8s
              restartPolicy: OnFailure

  • .spec.schedule : cron 명령 설정과 동일 (위는 1분)

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

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가지 예제로 배우는 컨테이너 관리자 자동화 표준 (동양북스)

IntelliJ 2020.3 의 기능 중에 Git 스테이징 지원 이라는 항목이 있다.

그래서 이걸 써보려고 위에 나와있는 것 처럼 환경 설정을 확인해봤다.

그런데 Git 설정을 들어가 보니 위의 그림처럼 Enable staging area 가 비활성화 되어있다. (처음에는 체크가 안된 상태로 비활성화 되어있었다. ) 

이것때문에 한참을 찾았는데 다음과 같이 해결을 하면 된다.

Version Control > Commit 항목에 보면 Use non-modal commit interface 라는 항목이 있다. 이걸 체크해주고 apply 해주면 위에 Enable staging area 가 활성화 된다.

활성화를 하고 나면 위와 같이 staged, unstaged 항목을 볼 수 있는 창을 사용할수 있게 된다.

Git 을 사용하면서 pull 을 받을때 다른 브랜치를 pull 받는 경우가 있다.

예를 들어서 나는 현재 A 브랜치에서 작업을 하고 있다. 그런데 B 브랜치의 내용을 A 브랜치로 pull 을 받아야 한다. ( 왜 이렇게 사용하냐고 묻는 다면.. 어쩌다 보니 이렇게 사용하게 됐다..)

그래서 한가지 궁금한게 생겼다. 

다른 브랜치를 pull 받는것과 merge 하는것과 차이가 있을까???

그럼 한번 실험을 해보자.

- master 브랜치, dev01 브랜치 생성

먼저 위 그림을 보자. 위 상황은 다음과 같다.

1. master 브랜치에서 test1.md 파일 생성후 커밋

2. dev01 브랜치 생성

3. dev01 브랜치에서 test2.md 파일 생성

- dev02 브랜치 추가 , test3.md 파일 추가 

그럼 위와 같은 상태가 된다.

- dev01 브랜치로 돌아가서 test2.md 파일 수정

1. dev01 브랜치로 checkout

2. test1.md, test2.md 파일 수정

3. 커밋

- dev02 브랜치로 가서 dev01 브랜치 pull

dev02 브랜치에 있는 tet1.md 파일과 test2.md 파일은 변경이 되지 않은 상태이다.

여기에서 다음가 같이 명령어를 쓴다.

git pull . dev01

리모트 저장소에 push 된 상태라면 명령어는 다음과 같이 된다. (지금 화면에서는 내가 리모트 저장소에 push 를 안한 상태로 local 만 사용중이기 때문에 . 을 사용한다.)

git pull origin dev01

음??  merge 를 한다고 나오네??

저장을 하게 되면 Git graph 는 다음과 같이 나온다.

결과적으로 서로 다른 브랜치에서 pull을 하게 되면 merge 를 하는것과 동일하게 동작을 한다.

-  Merge 확인해보기

dev03 브랜치를 만들어서 dev01 로 merge 를 해보자.

dev03 브랜치에서 test4.md 파일을 만들고 커밋을 했다.

dev02 에서 merge 를 한다는 것이 dev01 에서 merge 를 해서  dev01 도 표현이 되었다.

위와 약간 차이가 있어서 다시 해보겠다.

위 사진은 다음과 같이 실험한 결과이다.

1. dev02 브랜치에서 test5.md 생성 후 커밋

2. dev03 브랜치 checkout

3. dev03 브랜치에서 test4.md 파일 수정 후 커밋

4. dev02 브랜치로 다시 checkout

5. dev02 브랜치에서 dev03브랜치 merge

결과적으로 아래 Merge branch 'dev01' into dev02 와 동일한 그래프가 나타난다.

내가 내린 결론은 현재 브랜치에서 다른 브랜치를 pull하게 되면 merge와 동일한 동작을 하게 된다 라는 것이다.

....  혹시 글을 읽고 잘못된 점이 있으면 댓글로 알려주세요. (제가 잘못 이해한것 일수도 있어서..)

사용중인 맥북을  Big Sur 로 업데이트 했더니 git 사용시 다음과 같은 에러가 났다.

➜  ~ git
xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

해결 방법은 다음과 같다.

xcode-select --install

이렇게 설치를 해주면 해결이 된다.

현재 시스템의 구성은 다음과 같다

MasterNode, Worker1, Worker2

여기에 테스트를 위해서 mysql 을 열려놨다. 해당 yaml 은 다음과 같다. 

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: spring
  name: deploy-mysql
  labels:
    app: mysql
spec:
  replicas: 2
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: MYSQL_ROOT_PASSWORD
        - name: MYSQL_DATABASE
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: MYSQL_DATABASE
        - name: MYSQL_USER
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: MYSQL_USER
        ports:
        - containerPort: 3306
          name: mysql
          protocol: TCP
        volumeMounts:
        - mountPath: "/var/lib/mysql"
          name: mysql-volume
          subPath: dbdata
      volumes:
      - name: mysql-volume
        persistentVolumeClaim:
          claimName: mysql-pvc

그런데 한가지 문제가 생겼다. 

나는 K8S 를 사용하기 위해 virtual box 에서 master, worker1, worker2 이렇게 순서대로 헤드리스로 기동을 시킨다.

그런데 가끔 worker2 가 Ready 가 되기 전에 deployment 의 replicaset 이 같은 노드에 할당 되는 상황이 발생했다.

그러다 보니 pod 가 정상적으로 뜨지 않게 되었다. 

그냥 Pod 를 실행시키는 거라면 nodeselector 를 설정하면 될텐데 Deployment는 어떻게 하는지 몰라서 찾아보니 다음과 같이 spec 에 affinity 를 추가하는 방법을 찾을 수 있었다. 

      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - mysql
            topologyKey: "kubernetes.io/hostname"

위 설정에는 affinity 설정중 podAntiAffinity 설정을 추가하였다. 설정을 차례대로 해석하면 다음과 같다.

podAntiAffinity : 이 pod 가 실행될때 다음 값이 참이면 안된다.

requiredDuringSchedulingIgnoredDuringExecution : 반드시 만족해야 한다. (또다른 설정으로는 preffered 가 있다.)

matchExpressions: label 이 key 는 app 이고 값은 mysql 인 label을 찾는다.

결과적으로 label 이 app 이고 값이 mysql 인 pod 가 존재하는 node 에서는 pod 가 실행되지 않는다.

그래서 replicas 가 2로 설정되어있기 때문에 각각의 pod 는 각각의 node 에 위치하게 된다. 

master01@master01-VirtualBox:~/k8s/mysql$ kubectl get po -n spring -o wide
NAME                           READY   STATUS    RESTARTS   AGE   IP            NODE                  NOMINATED NODE   READINESS GATES
deploy-mysql-84f7bb885-rn9tz   1/1     Running   1          27h   10.244.1.80   worker01-virtualbox   <none>           <none>
deploy-mysql-84f7bb885-zqlmw   1/1     Running   1          26h   10.244.2.64   worker02-virtualbox   <none>           <none>

이거 이외에도 다양한 표현식으로 컨트롤이 가능하다. 

더 자세한 것은 아래 도큐먼트 참고하길 바란다.

v1-18.docs.kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/

- 열편집
Alt + Ctrl + Shift 누르고 방향키

- 터미널 열기
Ctrl + `