20220517 필기노트

https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/

kubectl api-resources 해보면 많은 오브젝트들을 확인할 수 있다.

node1에 zsh이랑 ohmyzsh설정하고..
플러그인에 kubectl이 있다
object를 resource로 만들 때 명령형으로 했지만 보통은 YAML방식을 사용한다.

링크는 오브젝트를 어떻게 YAML방식으로 쓸 것인가에 대한 내용임.

AKMS는 항상 정의해주어야하므로 기억해두자.

KIND는 대부분 단수로 되어있고 대소문자를 구분하는 특징들을 기억해두자.

오브젝트의 종류에 따라서 지원되는 api버전이 다르다
metadata는 data를 설명하기 위한 data이다. 그래서 metadata에는 이름, 레이블, 주석(annotation)들을 붙이게 된다.

가장 중요한 부분인 spec은 오브젝트의 어떤상태를 선언하는지를 정의하게 된다.

kubectl get nodes			#node와 관련된 리소스를 보겠다
kubectl get services		#service와 관련된 리소스를 보겠다
kubectl get pods			#pod와 관련된 리소스를 보겠다

### 숏네임이 있지만 YAML파일에서는 사용할 수 없다.

v1만 있는거는 쿠버네티스가 처음 생겼을 때 부터 있던 애들임

API레퍼런스
https://kubernetes.io/ko/docs/reference/

https://kubernetes.io/ko/docs/concepts/overview/kubernetes-api/

---

오브젝트의 버전

• Stable
  - v1, v2
  • vX
• Beta
  - v1betaX, v2betaX
• Alpha
  - v1alphaX, v2aplhaX
  

Alpha -> Beta -> Stable

• v1aplha1 -> v1apha2 -> v1alpha3 -> v1beta1 -> v1beta2 -> v1

쿠버네티스에서는 베타라고해서 꼭 불완전하지는 않다. 충분한 검증을 통해 오류는 없다. 다만 버전이 올라가게 되면 기능에 대한 변경이 있을 수 있다. 이렇게 기능이 변경될 때 downtime이 발생할 수 있다.

Misson Critical인 고가용성을 유지해야 하는 서비스에서는 가능하면 beta버전의 api는사용하지 않는것을 권장한다.

alpha버전은 기본적으로 비활성화 되어있고 개발중인 API들이라 실재 사용자 입장에서는 사용할 일이 거의 없다.

kubectl api-versions		#현재 버전에서 지원되는 API들의 목록
							#오브젝트의 버전을 확인가능하다.

kubectl explain pods

### 우리가 정의할 수 없는 것들은 Read-only라고 나와있다.

kubectl explain pods.spec
kubectl explain pods.spec.containers
kubectl explain pods.spec.containers.ports
kubectl explain pods.spec.containers.ports.containerports

kubectl explain pods.spec.containers --recrusive	#계층적으로 보게 해준다.

### 이런식으로 YAML파일 작성시 필요한 요소들을 확인할 수 있다.
### 인터넷에서 검색해서 복붙하지말고 이렇게 정확한 문서정의를 확인하고 직접 작성해보는 것을 연습해보자.

spec:
containers:
-
이 부분은 꼭 선언해야한다

---

오브젝트 관리

https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/object-management/

명령형 커맨드는 YAML 파일을 정의하지 않고 오브젝트를 생성하는 것임

ohmyzsh 적용 하고나서..

YAML파일 작성하기 전에

kubectl run myweb --image httpd
kubectl get pods
kubectl get pods

kubectl get pods -o wide
kubectl get pods -o yaml
kubectl get pods -o json
kubectl describe pods myweb

### 이런 정보들은 etcd에서 가져오는 것임

리소스 자체에 대한 로그들임

kubectl logs myweb
kubectl get pods
kubectl describe pods myweb
kubectl get pods myweb

kubectl logs myweb			#로그를 볼 수있는건 pod밖에 없기 때문에 pods를 지정하지 않는다.

kubectl delete pods myweg

kubectl run myubuntu --image ubuntu:focal
kubectl get pods
kubectl logs myubuntu
kubectl describe pods myweb

### 기본원칙은 종료되지 않는 서비스를 컨테이너로 만들어서 서비스하는데
### 그럼 기본적으로 -d 옵션으로 하는

kubectl run myubuntu2 --image ubuntu:focal -it bash
kubectl delete pods myubuntu myubuntu2

### 이렇게도 가능은한데 쿠버네티스는 기본적으로 이런 것을 위해 사용하지는 않는다.

---

YAML 파일로 파드 정의

kubectl explain pods
kubectl explain pods.apiVersion
kubectl explain pods.kind
kubectl explain pods.metadata
kubectl explain pods.spec

vi myweb.pod

apiVersion: v1
kind: Pod			#kubectl api-resources에서 볼 수 있음
metadata:
  labels:
    run: myweb
  name: myweb
spec:
  containers:
  - image : httpd
    name : myweb

질문
저는 kubectl get pods -o yaml 명령어와 kubectl explain pods.spec 등등..으로 찾아보면서 yaml파일을 작성하려고 했는데요. 무엇이 자동으로 생성되는것인지 아닌지 구분하기가 어렵더라구요..
최소한의 구성요소인지 아닌지 read-only말고도 판단하는 방법이 있을까요?
답변
--require-- 설정이 되어 있는 것이 최소한 필요한 구성입니다.
확인
image의 경우 require이라고 되어있지 않음..
이런 경우에는 image는 당연히 필요한 요소라 되는건가요??

kubectl create -f myweb.pod

kubectl get pods
kubectl logs myweb
kubectl describe pods myweb
kubectl get -f myweb.yaml
kubectl describe -f myweb.yaml

kubectl delete -f myweb.yaml

kubectl get pods -o yaml

하나의 Pod에 몇개의 컨테이너를 배치할지 정할 수 있다.
근데 여기서 주의할 점은 2개 이상의 다른 종류의 컨테이너를 배치하는것은 antipattern이다.
만약에 2개이상의 다른 컨테이너를 배치한다면 그 컨테이너는 매우 밀접한 컨테이너

질문
2개 이상의 컨테이너종류로 구성된 컨테이너로 구성된Pod에서 확장할 때 전체를 동시에 확장하나요 특정 컨테이너만 확장하게 할 수 있나요?
Pod로 구성해서 Pod를 확장시키는 것임

하나의 Pod에서는 네트워크와 볼륨을 공유한다.

Back-off하면 원래상태로 돌아가는것임

포트가 겹쳐서 두 개를 사용할 수는 없게 되는것임
containers에는 리스트형식이라 순서가 존재한다.

이상황에서

오류가 난다
컨테이너의 이름을 지정하라는 오류메시지..
Pod에 컨테이너가 하나일 때는 괜찮았지만 지금은 컨테이너가 2개이상이라서 지정해주어야함

node3로 ssh접속하고..

확인해볼 수 있다.

파드 디자인
단일 컨테이너: 일반적인 형태
멀티 컨테이너: 메인 애플리케이션에 확장 하기위한 컨테이너를 추가하는 형식

---

숙제 정리
https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns/
sidecar는 기능의 확장

앰버서더 형식은 대사관이라는 뜻으로 프록시형태가 일반적이다. 예를들어 DB를 여러개를 접속하기 위해서 LB를 설치하는 식

어뎁터 형식은 외부에서 들어오는 상황에서 어떤 데이터를 예를들어 로그데이터를 가지고 올 때 부터 sort등 표준화된 형식으로 변환해주는 것

나중에 쿠버네티스 실력이 올라갔다면 한 번 쯤은 공부해볼만한 책임

지울 때
kubectl get pods
kubectl delete -f myweb

---

포트 포워딩

0~1023번 포트를 열기 위해서는 관리자권한이 필요하다.
테스트하고 디버깅하기 위한 용도로 쓰는 것이고 외부에 노출 시키기 위해서 사용하지는 않는다.
서비스라는 오브젝트를 만들어서 사용하는것만이 외부에 포트를 노출 시키는 것이 가능하다.

---

Namespace

https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/names/

uid는 오브젝트를 완전하게 구분할 수 있는 것임

RFC는 ARPAnet advanced research pro...는 인터넷 미국방부가 만든것임
대학생이 ARPAnet을 공부하다가 만든 문서가 RFC Request For Comments

지금은 IETF에서 RFC라는 문서를 관리하고 뒤에 숫자가 붙는데 이것이 지금 인터넷의 표준이 되었다..

https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/namespaces/

kubectl get namespaces
kubectl get ns
kubectl get pods --all-namespaces
kubectl get pods --namespace default
kubectl get pods - default
kubectl get pods
kubectl get pods -n kube-public
kubectl get pods -n kube-system
kubectl het pods -n kube-lease
kubectl get leases -n kube-node-lease
kubectl get nodes				#lease는 HB라고해서 HeartBeat 살아있는지 확인하는 것임

kubectl create namespace developments
kubectl get ns
kubectl delete ns developments
kubectl get ns

kubectl explane namespace.spec		#Finalizer는 리소스를 지울 때 어떻게 할 것인가에 대한 내용
cd ~/namespace
vi dev-ns.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: dev

kubectl create -f dev-ns.yaml
kubectl get ns
kubectl run myweb --image httpd -n dev

kubectl get pods
kubectl get pods -n dev
kubectl delete pods myweb -n dev		#해당되는 namespace에 있는 pod를 지워주어야함

이렇게 리소스를 분리하는데에 사용된다.
RBAC: 권한을 NS에 설정
기본적으로 우리는 디폴트 네임스페이스를 사용하고 있다는 것을 꼭 기억하자.
사용자에 따라 개발환경 프로덕션환경에 따라 서비스별 등등의 분리 용도로 사용될 수 있다.

---

Label과 Selecter

https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/labels/

이런 정보들을 붙여주는게 좋겠다
일종의 태그
식별에 사용한다.

kubectl get pods --show-labels		#레이블을 확인할 수 있다.
kubectl get pods xxx -o yaml
kubectl describe pods xxx
kubectl label pods myweb APP=apache
kubectl get pods --show-labels
kubectl label pods myweb ENV=developments
kubectl label pods myweb ENV=staging
kubectl label pods myweb ENV=staging --overwrite
kubectl label pods myweb ENV-

ls
cd ..
mkdir label
cd label
vi myweb.yaml
kubectl create -f myweb.yaml
kubectl get pods --show-labels

label 규칙

kubectl get nodes --show-labels

AWS,GCP,Azure에 필요한 label들이 또 다르게 예약 되어있다.

selecter..
이름만으로는 부족하다!

kubectl get pods --show-labels
kubectl get pods -l APP=apache

selecter 방법도 일치성 기준과 집합성 기준이 있다.

이것이 일치성
=과 ==를 크게 구분하지 않음
!= 하면 아닌것

집합성은
in
not in
exists <- 키만 매칭 kubectl get pods -l 'APP'
doesnotexists kubectl get pods -l '!APP'

이렇게 밸류가 2개가 들어갈 수 있다.

---

Annotation

주석이긴한데 주석이라는 의미만 있지는 않음
어노테이션은 label과 거의 흡사한데 비-식별 데이터이다.

클라이언트가 메타데이터를 검색할 수는 있다.
이 메타데이터 정보를 가지고 무언가 하기 위해서 사용되기도 한다.

다른 애플리케이션 입장에서는 무언가 정보가 될 수 있다고 한다.

규칙

이렇게 다른 애플리케이션이 관리하기 편하게 사용하기도 함

kubectl annotate pods myweb created-by=Jang
kubectl get pods myweb -o yaml | head
kubectl annotate pods myweb created-by=Kim
kubectl annotate pods myweb created-by=Kim --overwrite
kubectl get pods myweb -o yaml | head
kubectl annotate pods myweb created-my
kubectl get pods myweb -o yaml | head

kubectl create -f myweb.yaml
kubectl get pods myweb-label-anno -k yaml

---

프로젝트 고민하기
프로젝트 주제는 대부분 쿠버네티스를 사용할 것이긴 하지만 거기에 +Alpha 를 생각할 것.

CI/CD Jenkins기반 + ansible + Helm Package
source 코드를 k8s로 배포하는것 까지
Helm Package
Github Action
Gitlab CI/CD--
ArgoCD
FluxCD
CircleCI--
AWS Code*
Azure
GCP

그리고 무언가를 하기위해서는 결국
Applicateion이 필요할 수 있다.
Wordpress Drupal 등등..
구글에서
Web App을 찾아보면 너무나도 많음
예를들어 Kubernetes에 App example
간단한 앱 DB

또는 멀티클라우드 어떻게 라우팅할 것인지.
테라폼으로도 가능

온프램과 오픈클라우드 하이브리드도 가능

프로젝트 주제와 진로와 아무 상관이 없으니 걱정말고 하고싶은데로 마음껏 고민해보기