20220518 필기노트

---

미국방성에서도 쿠버네티스를 이용해 항공기시스템을 업데이트하려는 시도가 있다.

https://www.aviationtoday.com/2020/10/09/first-dod-kubernetes-installed-u-2-dragon-lady/

https://www.militaryaerospace.com/computers/article/14178297/b21-software-autonomy

---

현업에서 사용되는 쿠버네티스의 예시

https://github.com/sysnet4admin/_Book_k8sInfra/tree/main/docs/k8s-stnd-arch/2022

https://github.com/sysnet4admin/_Book_k8sInfra/blob/main/docs/k8s-stnd-arch/2022/2022-k8s-stnd-arch.pdf

프로젝트해볼만한 주제
knative 서버리스도구
AWSLambda
Azure Function
GCP Fuction

Serverless

멀티 클러스터 매니지먼트
Kubernetese cluster API
Onpremise k8s
AWS EKS
Azure AKS
GPC GKE
이것들을 한 꺼번에 관리할때 사용하는 것이 Cluster API
HELM은 패키지 관리자
LENS는 GUI기반의 쿠버네티스 관리 도구

---

파드 라이프사이클

https://kubernetes.io/ko/docs/concepts/workloads/pods/pod-lifecycle/

Pod 상태

• Pending: 스케쥴링되기 전, 이미지를 받기 전, 컨테이너가 준비되기 전
  

• Running: 컨테이너가 실행 중, 실행 전, 재시작 중
  

• Succeeded: 정상종료, RC = 0

• failed: 비정상종료, non-zero상태

• Unknown: 통신이 안돼서 상태를 알 수 없을 때

kubectl delete pods myweb
kubectl delete pods myweb-label

### 했을 때 약간 시간이 걸리는데 이때 30초 안에 종료되면 정상종료 이후면 강제종료의 형태가 된다.
### 정상종료는 SIGTERM 15시그널
### 강제종료는 SIGTERM 9번시그널

자동완성기능을 사용할 때 기본적으로 디폴트 네임스페이스에서 찾게됨
이 때 네임스페이스를 지정해주면 디폴트 네임스페이스가 아니더라도 찾을 수 있게 된다.

꿀팁입니다 꿀팁! -장성균 강사님

컨테이너의 마지막 상태도 확인할 수 있다.
어떤 명령어를 이용해서 상태체크를 할 지 연습많이 해보기

Hook의 개념

중간에 내가 어떤 정보를 밀어넣는것을 말함

Container 상태
Waiting: 이미지 받기 전, 볼륨 연결 되기 전
Running: 실행중
Terminated: 종료
대부분의 오류는 이미지 자체가 어플리케이션에 적용하지 못할 때 생긴다고 한다..

kubectl explain pods.spec.restartPolicy		#재시작 정책 (Always, Onfailure, Never)
kubectl explain pods.spec

### Camel pattern
### 첫단어는 소문자 두 번째 부터는 대문자를 사용하는 단어 패턴

지수 백 오프

kubectl get pods
watch -n1 kubectl get pods
kubectl get pods --watch
watch kubectl get pods,nodes,services		#이렇게도 가능
kubectl get pods,nodes,services				#가능
kubectl get pods,nodes,services --watch		#불가능

### 점점 재시작하는 기간이 길어진다 그 현상이 지수 백오프임.

없는 이미지를 선택했기 때문에 이미지 풀링이 안될 것이고 이러면 재시작 정책에 의해서 log backoff로 인해서

jitter편차라고 해서 정확히 똑같은 시점에 다시 무언가를 하다보면 문제가 발생하기 때문에 약간씩의 편차를 두게 된다.

---

컨테이너 프로브

• livenessProbe
  컨테이너가 동작 중인지 여부를 나타낸다.

• readinessProbe

• startupProbe
  
  
  startupProbe는 파드가 실행되고나면 livenessProbe를 실행시킴 일종의 initialDelayProbe같은 느낌인데 좀더 정교한..

livenessProbe를 추가하는 방법

프로브 메커니즘

• httpGet
  • Web, WebApp
  • 응답 코드 2xx, 3xx
    http 응답코드에 대해서 알아야함
    1xx 정보
    2xx 성공
    3xx 리디렉션 http를 https로 바꾸어주는 것도 300번이기 때문에 이것도 성공의 일부로 봐야한다고 한다.
    4xx 클라이언트 오류
    5xx 서버 오류

• tcpSocket
  
  3way handshaking을 기반으로 작동함

https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

• grpc
  grpc로 만들어진 어플리케이션의 진단을 말함

• exec
  명령어의 상태코드로 진단을 함
  예를들어 mysql에서는 mysqladmin ping으로 확인이 가능하다.

이런식으로 명령어로 체크를 해주는 경우도 따로 알고있어야한다.

프로브 결과

• success
• failure
• unknown

kubectl explain pods.spec.containers.livenessProbe

Threshold 특정 기준선을 이야기함, 임계값, 한계선
initialDelaySeconds
JAVA코드는 실행하는데 오래걸린다.
그럴 경우에 프로브를 보냈을 때 실패로 간주해버리기 때문에 재시작을 걸어버려서 똑같은 현상이 발생하게 된다. 그래서 초기에는 Delay를 걸어주게 된다.

실습 예제

kubectl create -f myweb-libeness.yaml
kubectl get pods
kubectl gor pods describe...
cp myweb-libeness.yaml myweb-libeness-err.yaml
code 

kubectl create -f myweb-libeness-err.yaml
kubectl get pods
kubectl get pods --watch

10초간격의 3번 실패로인해 재시작

pod 삭제

startupProbe 실습

kubectl create -f myweb-startup.yaml

kubectl describe pods myweb-startup

정상적으로 고치고..

apiVersion: v1
kind: Pod
metadata:
  name: myweb-startup
spec:
  containers:
    - name: myweb
      image: httpd
      ports:
        - containerPort: 80
          protocol: TCP
      livenessProbe:
        httpGet:
          path: "/"
          port: 80
      startupProbe:
        httpGet:
          path: "/"
          port: 80

이런식으로 어플리케이션이 잘 작동하는지 확인할 수 있다

Dockerfile에서도 healthcheck기능이 있지만 명령어실행하는 기능밖에 없다고 한다.
https://docs.docker.com/engine/reference/builder/#healthcheck

---

프로젝트 주제

https://k3s.io/
쿠버네티스보다 작다는 의미에서 k3s

이건 VM에 하는건 아니고 IoT나 Edge에서 사용됨

https://www.raspberrypi.org/

라즈베리파이 여러 개로 쿠버네티스 클러스터를 구현하는 프로젝트도 있었다고 한다

ARM은 전력대비 퍼포먼스가 좋은 편이라고 한다.

https://rancher.com/
suse linux에서 만든 오픈소스임
rancher는 멀티클라우드 하이브리드클라우드일 경우에 rancher라는 하나의 도구에서 관리할 수 있게 해준다.

web ui도 제공을 한다고 한다.

---

Wordload Resource contorller

Workload라는 것이 결국에는 Application을 실행하는 것이다.
Controller는 Pod들의 집합이라고 생각해두자
Self Healing을 하기 위해서는 Controller가 필요하다고 한다.


쿠버네티스의 최대 핵심..

kubectl api-resources | more

kubectl get pods
kubectl get pod
kubectl get po

kubectl get replicationcontrollers
kubectl get replicationcontroller
kubectl get rc

### 상관없음

레플리케이션 컨트롤러의 동작방식 - Pod가 많아지면 줄이고 적으면 만드는 역할을 한다.
그리고 교체를 하는데 기존의 Pod가 만들어지는게 아니라 전혀 새로운 Pod가 만들어짐

kubectl explain rc
kubectl explain rc.spec

kubectl explain rc.spec.template

내가 관리하는 Pod가 무엇인지를 구분하기 위해서 label을 설정해주어야한다. singleton Pod에서는 label이 그렇게 중요한 요소가 아닐 수 있지만 Replication controller입장에서는 lable이 selecting시에 중요하게 작동한다.

vi myweb-rc.yaml

apiVersion: v1
kind: ReplicationController
metadata:
  name: myweb-rc			#Pod의 이름은 이것 뒤에 랜덤하게 추가됨
spec:
  replicas: 3
  selector:
    app: web
# Pod Configure
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: myweb
          image: ghcr.io/c1t1d0s7/go-myweb
          ports:
            - containerPort: 8080
              protocol: TCP

kubectl create -f myweb-rc.yaml
kubectl get rc
kubectl get pods
kubectl get rc,pods
kubectl get rc,pods -o wide
kubectl get rc -i wide
kubectl get pods --show-labels

이렇게 관리하는 것임

watch -n1 kubectl get pods --show-labels

다른 창에서..
kubectl label pods myweb-rc-szq68 app=database --overwrite
kubectl label pods myweb-rc-szq68 app=web --overwrite

관리할 녀석이 4개가 되면서 하나는 터미네이팅 되어버림
가장 최근에 만들어진게 지워지는 원칙이 있음

@@@@@@@@@@@2
숙제: 이거 정리하기
@@@@@@@@@@@

---

RC 스케일링

watch n1 -d kubectl get rc,pods
kubectl scale rc myweb-rc --replicas=5
kubectl scale rc myweb-rc --replicas=3

replace를 사용하면 yaml파일의 변경사항을 적용시킬 수 있다

와.. 연기력 대박.. 템플릿의 정보를 바꾼것이지 Pod의 정보를 바꾼것은 아니기 때문에 변경되지 않음

kubectl delete pods -l app=web

### 이런식으로 lable을 가지고 검색뿐만 아니라 명령시에도 사용할 수 있다.

kubectl delete pods --all

그리고 kubectl explain에 보면 replace가 가능한지 안한지가 명시되어 있다고 한다.

kubectl patch -f myweb-rc.yaml
kubectl patch -f myweb-rc.yaml '{"spec": {"replicas": 2}}'
kubectl patch rc myweb-rc -p '{"spec": {"replicas": 2}}'

### 패치할 부분을 yaml이 아니라 json형식으로 수정하게 된다.
### replace는 우리가 완전하게 제공해야하는데
### patch는 변경하고자 하는 일부분만 제공해도 된다.
### 그래서 명령형 커맨드로 만든 Pod를 수정할 때 patch가 이용됨

vi replicas.json

{
   "spec":
  {"replicas": 2}
}

kubectl patch rc myweb-rc --patch-file replicas.json

한 가지가 더 있음

kubectl edit -f myweb-rc.yaml
kubectl edit rc myweb-rc
kubectl edit rc/myweb-rc

### 그렇다고 해서 yaml파일을 수정한 것이 아니라.
### 해당 리소스의 yaml정보만 수정한 것이다.
### 안되면 안된다고 로그가 찍힘

---

선언형 오브젝트 구성

kubectl delete -f ...
kubectl apply -f myweb-rc.yaml

#(수정)

kubectl apply -f myweb-rc.yaml

kubectl apply -f rc/

### 이런식으로 모든 yaml파일을 적용시킬 수 있다.

---

logs

kubectl describe rc myweb-rc
kubectl logs rc/myweb-rc

---

컨트롤러만 제거

kubectl delete rc myweb-rc
kubectl get pods

---

ReplicaSets

ReplicationController보다 기능이 조금 더 많다.

kubectl api-resources | grep replicasets
kubectl api-resources | grep apps/v1
kubectl expalin replicaset
kubectl explain rs.spec.template

### 등등 모두 똑같지만 달라지는 부분은

kubectl explain rs.spec.selector
kubectl explain rc.spec.selector

kubectl explain rs.spec.selector.matchLabels		#map 키밸류를 쓰게 됨
vi myweb-rs.yaml

apiVersion: apps/v1
kind: RelicaSets
metadata:
  name: myweb-rs
spec:
  replicas: 3
  selecotr:
    matchLabels:
      app: web
      env: dev
  template:
    metadata:
    labels:
      app: web
      env: dev
    spec:
      containers:
      - name: myweb
        image: ghcr.io/c1t1d0s7/go-myweb
        ports:
          - containerPort: 8080
            protocol: TCP

kubectl create -f myweb-rs.yaml
kubectl get rs -i wide
kubectl get pods --show-labels
kubectl describe rs myweb-rs
kubectl get rs ... yaml
kubectl get pods --show-labels
kubectl labels po myweb-rs-vtm24 app-

똑같이 작동하는걸 볼 수 있음

kubectl explain rs.spec.selector
kubectl explain rs.spec.selector.matchExpressions

일치성과 집합성의 차이가 있음
일치성은 key와 value가 매칭이 되어야한다.

cp myweb-rs.yaml myweb-rs-set.yaml
vi myweb-rs-set.yaml

kubectl get po --show-labels
kubectl create -f myweb-rs-set.yaml
kubectl get po --show-labels
kubectl get rs 
kubectl get rs -o wide
kubectl het pods --show-labels

셀렉터가 구분을 어떻게 하는지가 신기함

kubectl scale rs myweb-rs --replicas=3

kubectl create -f myweb-rc.yaml
kubectl get rs,rc,pods

이렇게 해도 셀렉터가 잘 구분하는게 신기하도다

kubectl get pod/myweb-rs-set-hqxcx -o yaml

이렇게 Pod에 어떤 controller에 의해서 제어되는지 구분이 됨
그래서 셀렉터가 잘 관리했던 것임

예전에는 이렇게 못했었다고 함

---

kubectl get --all

kubectl get -n kube-system rs
kubectl get -n kube-system rs coredns-8474476ff8 -o wide

이렇게해서 보고싶은 내용을 자세히 골라서 볼 수 있다.

---

교재에 목차에서..
6.2 Pod
6.3 ReplicaSet에 대해서 공부했음
책에 있는 실습도 한 번 해보길 바람 !
11.3.2에 Pod의 생애주기도 있음
이 정도를 배운것임..

내일은 데몬셋, 잡, 크론잡 을 볼것임
여기까지 보면 기본적인 내용은 본거고
디플로이먼트 스테이플풀셋은 나중에
서비스가 매우 중요한 부분임
Pod를 외부로 노출 시키는 것임 기능이 많으므로 잘 배워야함.