65/120

김건호·2022년 5월 17일

쿠버네티스 오브젝트 이해하기

오브젝트를 통해 리소스를 생성

오브젝트의 버전

https://kubernetes.io/ko/docs/reference/using-api/#api-%EA%B7%B8%EB%A3%B9

kubectl api-versions

apps/v1

apps: 그룹
v1: 버전

그룹이 없는 api는 core 그룹

Stable
- vX
- v1, v2
- 안정화된 버전
Beta
- v1betaX, v2betaX
- 충분히 검증 오류 X
- 버전이 올라가되면 기능 변경이 있을 수 있음
- downtime 발생할 수도 있음: 특정 기능을 사용하기 위해 재시작
- Mission Critical
Alpha
- v1alphaX, v2alphaX
- 기본 비활성화
- 개발 중인 API

Alpha -> Beta -> Stable

v1alpha1 -> v1alpha2 -> v1alpha3 -> v1beta1 -> v1beta2 -> v1

API 그룹의 버전에 관련된 내용
https://kubernetes.io/ko/docs/reference/using-api/#api-%EA%B7%B8%EB%A3%B9

오브젝트 명세(spec)와 상태(status)

명세 : 어떻게 정의할 것인지, 오브젝트의 상태는 어떤지(우리가 지정)
상태 : 쿠버네티스가 리소스를 만든 이후에 현재상태를 지정(쿠버네티스가 지정)

오브젝트 정의

쿠버네티스에서 생성할 수 있는 오브젝트 목록 확인

kubectl api-resources

오브젝트 정의 파일

apiVersion:
kind:
metdata:
spec:

apiVersion: apps/v1 : 지원하는 오브젝트의 버전
kind: Deployment : 오브젝트의 종류 오브젝트에 따라 지원하는 api버전이 다 다름. api의 버전은 오브젝터의 종류에 영향을 받게 됨 kubectl api-resources에서 NAME과 KIND는 다름
metadata: 오브젝트의 메타데이터를 지정, 메타데이터라고 하는건 데이터를 설명하기 위한 데이터
spec: 오브젝트에 대한 선언.하위에 여러가지 들어갈 수 있음

오브젝트 정의 시 확인하는 명령어

kubectl explain <확인하고자 하는 리소스의 이름>

FIELDS: 항목 yaml파일에서 정의를 해야하는 목록
필드가 더이상 없으면 자기자신만 있음 -> 자기자신이 끝난다
--recursive 붙이면 이름만 계층적으로 나옴

kubectl explain pods
kubectl explain pods.metadata
kubectl explain pods.spec
kubectl explain pods.spec.containers
kubectl explain pods.spec.containers.images
kubectl explain pods.spec --recursive

API 레퍼런스
https://kubernetes.io/ko/docs/reference/
https://kubernetes.io/ko/docs/concepts/overview/kubernetes-api/

쿠버네티스 오브젝트 관리

명령형 커멘드: kubectl 명령으로만 구성
- kubectl create
- kubectl run
- kubectl expose
명령형 오브젝트 구성: YAML 파일을 순서대로 하나씩 실행
- kubectl create -f a.yaml # -f는 파일이라는 뜻
- kubectl replace -f a.yaml
- kubectl patch -f a.yaml
- kubectl delete -f a.yaml
선언형 오브젝트 구성: YAML 파일의 모음을 한번에 실행
- kubectl apply -f resources/

workload - pod

컨테이너의 컬렉션
쿠버네티스는 컨테이너 직접 컨트롤하지않음 -> pod 관리

vagrant@node1:~/pod$ kubectl explain pods
KIND:     Pod
VERSION:  v1

DESCRIPTION:
     Pod is a collection of containers that can run on a host. This resource is
     created by clients and scheduled onto hosts.

파드 생성 및 관리

명령형 커맨드로 파드 생성

kubectl run myweb --image httpd

pod/myweb created # 오브젝트 리소스만들면 오브젝트종류/이름 어떻게 되었다고 나옴

파드 목록 확인

kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
myweb   1/1     Running   0          39s

1/1에서 뒤에는 컨테이너 총 개수 앞에 1은 준비된 컨테이너 수

특정 파드 확인

kubectl get pods myweb

파드 상세 정보

kubectl get pods -o(output 옵션) wide

kubectl get pods -o yaml

kubectl get pods -o json

kubectl describe pods myweb

descfribe에서만 볼 수 있는정보 -> events 중요정보

리소스의 라이프사이클에 대한 정보
리소스를 만들기 위해 쿠버네티스가 이 리소스가 뭐가 만들어졋고 언제 만들어졋고 하는 리소스에 대한 로그 시간순으로 나ㅏ오게 됨 과거로부터

애플리케이션 로그

kubectl logs myweb

파드 삭제

kubectl delete pods myweb

pod는 종료되지 않는 앱을 실행하는 것이 원칙
kubectl run myubuntu --image ubuntu:focal
kubectl describe pods myubuntu
crashloopbackoff 에러

YAML 파일로 파드 정의

myweb.yaml

apiVersion: v1
kind: Pod 
metadata:
  name: myweb
spec:
  containers:
    - name: myweb
      image: httpd
      ports:
        - containerPort: 80
          protocol: TCP

kubectl explain pods

파일을 이용하여 pods 생성

kubectl create -f myweb.yaml

파일을 이용하여 pods 정보 확인

kubectl get -f myweb.yaml

파일을 이용하여 pods 구체적인 정보 확인

kubectl describe -f myweb.yaml

파일을 이용하여 pods 삭제

kubectl delete -f myweb.yaml

kubectl 명령의 서브 명령

create
get
describe
logs
delete
replace
patch
apply
diff

pod관련 문서
https://kubernetes.io/ko/docs/concepts/workloads/pods/

파드 디자인

단일 컨테이너: 일반 적인 형태
멀티 컨테이너: 메인 애플리케이션이 존재 매인 애플리케이션 기능을 확장 하기 위한 컨테이너를 배치

pod하나에 wp,mysql 컨테이너를 하나씩 구성해선 안 됨 -> Anti Pattern

사이드카 패턴
https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns/

sidecar: 기능의 확장 ex -> 로그를 로컬에 남기면 로그를 가지고 다른 로그서버로 전송

ambassador: 프록시/LB 네트워크 흐름을 내부에서 파드 외부로 나가게 하는 네트워크 흐름을 가지고 있는 컨테이너, 일반적으로 프록시 형태

adpator: 출력의 표준
앱이 로그를 남김. 중앙 집중화된 모니터링 시스템이 있음 수도 없이 많은 정보를 가져오는데 얘가 알아들을 수 있는 표준화된 포맷이 있는데 앱마다 로그 형태가 다른 경우, 가지고 올때부터 표준화시킴 얘가 알아들을 수 있게 sort도 하고 변경도하고 이런작업을 해주는게 어댑터

pod 특징

하나의 파드에는 네트워크와 볼륨을 공유
컨테이너가 하나던 여러개던 파드에 하나의 ip만 부여 -> network 를 다른컨테이너가 공유

포트 및 포트 포워딩

테스트 & 디버깅 목적

kubectl explain pods.spec.containers.ports

apiVersion: v1
kind: Pod
metadata:
  name: myweb
spec:
  containers:
    - name: myweb
      image: httpd
      ports:
	    - containerPort: 80# 컨테이너가 사용할 포트 -> 실제포트가 80이 되느냐는 아니다 실제 서비스포트는 808이다 그냥 정보
	      protocol: "TCP"
	      # 단순히 정보일 뿐이다


kubectl port-forward myweb 80:80
kubectl port-forward pods/myweb 80:80
포트를 바인딩할 수가 없다 0~1023 열려면 관리자 권한이 필요함
sudo 하면 되지만 그냥 8080:80으로

이름 & UID

이름: 네임스페이스 유일
UID: 클러스터에서 유일

Namespace

리소스를 분리

서비스 별
사용자 별
환경: 개발, 스테이징, 프로덕션

서비스: DNS 이름이 분리되는 용도
RBAC: 권한을 NS에 설정

kubectl get namespaces(ns)

kube-system: Kubernetes의 핵심 컴포넌트
kube-public: 모든 사용자가 읽기 권한
kube-node-lease: 노드의 HeartBeat(노드가 살아있나 죽었나) 체크를 위한 Lease 리소스가 존재
default: 기본 작업 공간

생성

kubectl create ns developments

namespace 삭제

kubectl delete ns developments -> 안에 리소스가 없어야함

namespace 확인

kubectl get pods -A | --all-namespaces

-n 옵션을 통해 namespace 지정하여 확인

kubectl get pods -n kube-system

pod의 이름은 namespace에서 유일 -> namespace가 다르면 pod의 이름은 같아도 됨
삭제 시 -n 을 지정하지않으면 default에 있는 같은 이름의 pod가 삭제되기때문에 주의

ns-dev.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: dev

kubectl create -f ns-dev.yaml

myweb-dev.yaml

apiVersion: v1
kind: Pod
metadata:
  name: myweb
  namespace: dev
spec:
  containers:
    - name: myweb
      image: httpd
      ports:
        - containerPort: 80
          protocol: TCP

kubectl create -f myweb-dev.yaml

kubectl delete -f myweb-dev.yaml

api-resources로 보면 namespace 필드가 있는데 namespace를 리소스마다 사용하는지 안하는지에 대한 정보 true 는 사용, false는 미사용

Label & LabelSelector

권장레이블

Label

aws의 태그와 비슷 리소스의 이름은 네임스페이스에서 유일해야함
레이블은 리소스에 하나이상 설정할 수 있음 중복해서 겹칠 수가 있음
레이블을 붙여서 오브젝트의 특성을 식별하는데 사용

레이블 확인

kubectl get pods --show-labels

kubectl get pods X -o yaml

kubectl describe pods X

레이블 관리

kubectl label pods myweb APP=apache

kubectl label pods myweb ENV=developments

kubectl label pods myweb ENV=staging

이미 세팅 되어 있기 때문에 덮어쓰려면 --overwirte 옵션을 사용해야함

kubectl label pods myweb ENV=staging --overwirte

kubectl label pods myweb ENV-

LabelSelector

검색 -> pod 여러개 있을때 N~NN 수천개 이름만 가지고 구별할 수 없기 때문
리소스 간 연결 -> 여러 타입의 오브젝트가 있는데 이 오브젝트간의 관계를 설정할때 레이블을 사용

일치성(equality base)

=
==
!=

kubectl get pods -l APP=nginx
kubectl get pods -l APP==nginx

kubectl get pods -l 'APP!=nginx'

집합성(set base)

in
notin
exists: 키만 매칭
- kubectl get pods -l 'APP'
doesnotexists: 키 제외 매칭
- kubectl get pods -l '!APP'

어떤 레이블을 사용해야 할까?
사용동기 예시 https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/labels/#%EC%82%AC%EC%9A%A9-%EB%8F%99%EA%B8%B0

레이블중에 kubernets.io/ k8s.io 들은 예약이 되어있음 -> 다른곳에서 쓰이고 있다

Annotations

레이블과 비슷
비 식별 메타데이타 -> 셀렉터가 없음
클라이언트가 이 메타데이터를 검색할 수 있음 -> 단순히 가져갈수도 있고
메타데이터로 작업을 하기 위해

명령형 커맨드

kubectl annotate pods myweb created-by=Jang

kubectl annotate pods myweb created-by=Kim --overwrite

kubectl annotate pods myweb created-by-

YAML 형식

apiVersion: v1
kind: Pod
metadata:
  name: myweb-label-anno
  labels:
    APP: apache
    ENV: staging
  annotations:
    Created-by: Ken
spec:
  containers:
    - name: myweb
      image: httpd
      ports:
        - containerPort: 80
          protocol: TCP

kubectl get pods -o yaml
로 보면 어노테이션이 붙어 있음, 만든적은 없지만 붙어있음 calico에 의해 만들어졌음 cni
pod 만들면 네트워크 제공하는게 calico 비식별 메타데이터를 붙임
calico가 관리하기 위한 용도로 붙여놓앗음

김건호

Ken, 🔽🔽 거노밥 유튜브(house icon) 🔽🔽

이전 포스트

64/120

다음 포스트