잡다한기술블로그

Pod 동작 flow

• '웹 서버 컨테이너 실행해줘' 명령 요청
• API에 Pod형태로 전달
• API가 문법이 제대로 된 문법인지 점검
  • Pod API 포맷에 맞는 정보가 입력되었는지 점검
• etcd에서 노드 정보를 받아 스케줄러에 전달
• 스케줄러가 어느 노드에서 실행할지 선택
  • Pod는 스케줄링을 받을 때, Pending 상태
• Pod를 노드에 배치
  • Pod는 노드를 배치 받으면 Running 상태
  • Pod가 배치 완료되면 Succeeded, 실패하면 Failed

Pod 관리하기

• 동작중인 파드 정보 보기
  • kubectl get pods
    • kubectl get pods --all-namespaces
  • kubectl get pods -o wide
  • kubectl describe pod webserver
• 동작중인 파드 수정
  • kubectl edit pod webserver
• 동작중인 파드 삭제
  • kubectl delete pod webserver
  • kubectl delete pod --all

Reference

따배쿠10강

Container 정리

• 컨테이너 사용 과정
  • 애플리케이션 생성
  • 컨테이너 빌드
  • 저장소(hub)에 push
  • 도커 플랫폼에 컨테이너를 올려 사용
• 컨테이너 하나 = 애플리케이션 하나

Pod 란?

• 컨테이너를 표현하는 k8s API의 최소 단위
  • API에서 컨테이너 동작은 불가능

• Pod에는 하나 또는 여러개의 컨테이너가 포함될 수 있음

Pod 생성하기

• kubectl run 명령(CLI)으로 생성
  • kubectl run webserver --image=nginx:1.14
• pod yaml을 이용해 생성 
  • kubectl create -f pod-nginx.yaml

Multi-container Pod 생성하기

• 두개의 컨테이너 정보를 포함한 yaml파일 생성
• kubectl create -f pod-multi.yaml
• 생성된 pods 확인

• multi-container pod에 web 컨테이너가 존재하므로 curl을 통해 웹 서버 접속 가능
• multi-container pod의 컨테이너 내부에 접근하는 방법
  • kubectl exec multipod -c nginx-container -it -- /bin/bash
    • -it은 터미널 만들고 인터렉티브하게 접속(root), /bin/bash는 bash 쉘로 실행
  • kubectl exec multipod -c centos-container -it -- /bin/bash
• multi-container는 같은 ip를 사용하기 때문에 centos에서 localhost를 통해 web에 접속 가능
  • curl localhost
• multi-container pod의 웹 애플리케이션 컨테이너 log 확인하는 방법
  • kubectl logs multipod -c nginx-container

Reference

따배쿠9강

yaml 템플릿

• 사람이 쉽게 읽을 수 있는 데이터 직렬화 양식

• 기본 문법
  • 구조화된 데이터를 표현하기 위한 데이터 포맷
  • Python처럼 들여쓰기로 데이터 계층을 표기
  • 들여쓰기를 할 때에는 Tab이 아닌 Space Bar를 사용
  • 가독성이 좋아 설정 파일에 적합한 형식
  • Scalar문법: ':'을 기준으로 key:value를 설정
  • 배열 문법: '-'문자로 여러개를 나열
  • kubernetes yam example
    • cat nginx-pod.yaml
• apiVersion:v1과 kind: pod가쿠버네티스용 문법임

API version

• alpha -> beta -> stable
• kubernetes Object 정의 시 apiVersion이 필요
• kubernetes가 update하는 API가 있으면 새로운 API가 생성됨

• API Object의 종류 및 버전
  • Deployment: apps/v1
  • Pod: v1
  • ReplicaSet: apps/v1
  • ReplicationController: v1
  • Service: v1
  • PersistentVolume: v1
• API 버전이 맞지 않으면 실행 x
• API 버전 확인 방법
  • kubectl explain pod

• API 버전이 다를때 파일 수정 방법
  • cat > [파일명]으로 파일 편집 시 저장 및 종류
    • Ctrl+D를 눌러서 저장 및 종료 

Reference

따배쿠8강

k8s namespace

• k8s api 종류 중 하나
• 물리적인 클러스터 하나를 여러 개의 논리적인 단위로 나눠서 사용
  • 쿠버네티스 클러스터 하나를 여러 팀이나 사용자가 함께 공유
  • 용도에 따라 실행해야 하는 앱을 구분할 때 사용
• 수 많은 pod를 용도에 따라 논리적으로 분류하여 활용하는 방법
• 통합솔루션에서

Example

• 롯데에서 클러스터 하나를 롯데 홈쇼핑, 백화점, 면세점에서 나눠서 사용한다고 가정
• 클러스터를 3개의 namespace로 구분하여 각 회사에 할당
  • blue (API - Pod - Service - P.V) -> 롯데 홈쇼핑
  • orange (API - Pod - Service - P.V) -> 롯데 백화점
  • green (API - Pod - Service - P.V) -> 롯데 면세점

네임스페이스 사용하기

• namespace 생성
  • CLI
    • kubectl create namespace blue
  •   yaml
    • kubectl create namespace green --dry-run -o yaml > green-ns.yaml
    • vim green-ns.yaml
    • kubectl create -f gree-ns.yaml
• namespace 관리
  • kubectl get namespace
  • kubectl delete namespace

네임스페이스 실습

• 시스템에 네임스페이스 개수 확인
  • kubectl get namespaces
  • master node에 기본으로 들어있는 namespace 종류
    • default - 네임스페이스 선택하지 않았을 때 기본 값
      • 명령시 네임스페이스명 지정하지 않으면 default 네임스페이스 결과 출력됨
    • kube-node-lease
    • kube-public
    • kube-system - master node의 운영환경에 필요한 pods들
      • api server, 스케줄러 등
•  네임스페이스의 pods 확인
  • kubectl get pods --namespace [네임스페이스명]
  • kubectl get pods -n [네임스페이스명]
• 모든 네임스페이스의 pods 확인
  • kubectl get pods --all-nm

• 네임스페이스 생성(CLI)
  • kubectl create namespace blue
• 네임스페이스 생성(yaml)
  • kubectl create namespace orange --dry-run -o yaml > orange-ns.yaml (yaml파일 생성)
  • vi orange-ns.yaml (yaml파일 수정)
  • kubectl create -f orange-ns.yaml (yaml파일로 생성)
• 네임스페이스에서 pod 생성하기
  • kubectl create -f nginx.yaml -n blue
  • yaml 파일 내에서 metadata에 namespace를 지정하여 입력 후 yaml파일로 pod 생성하면 지정된 namespace에 pod 생성
• 네임스페이스 switch - 기본으로 사용할 네임스페이스를 default가 아닌 다른 것으로 변경
  • namespace를 포함한 context 등록
    • kubectl config --help (config 도움말)
    • kubectl config view
    • kubectl config set-context blue@kubernetes --cluster=kubernetes --user=kubernets-admin --namespace=blue
  • 현재 context 확인
    • kubectl config current-context
  • 등록된 namespace로 context 변경
    • kubectl config use-context blue@kubernetes

• 네임스페이스의 pod 삭제하기
  • kubectl delete pods mypod -n default
• 네임스페이스 삭제하기
  • 네임스페이스 삭제하면 안의 내용물들도 다 삭제됨
    • kubectl delete namespace blue

Reference

따배쿠7강

쿠버네티스에서 컨테이너 동작 Flow

사용 주체

• 개발자
• 운영자

동작 순서

• 컨테이너 빌드
  • main ui container, log in container, pay container 등
• 저장소에 컨테이너 이미지 push
  • 사내 저장소, docker hub 등
• 사용 주체가 명령어를 통해 control-plane에 컨테이너 실행 요청
  • 명령어: CLI(kubectl), yaml 등
• control-plane의 rest api server에서 요청을 받아 어느 노드에 컨테이너를 배치할지 스케줄러에게 요청
• control-plane의 스케줄러가 노드의 상태를 보고 적합한 노드를 선택해 rest api server에게 응답
• control-plane의 rest api server가 응답 받은 내용을 실행할 노드의 kubelet에 요청(전달)
• kublet이 요청을 받아 도커 명령어로 바꿔서 도커에게 실제 컨테이너 실행 요청
• 도커가 저장소에서 컨테이너 이미지를 검색한 후 컨테이너로 실행한 후 pod라는 단위로 관리

쿠버네티스 컴포넌트

• 마스터 컴포넌트
  • etcd
    • key-value 타입의 저장소
    • 워크 노드에대한 상태 정보 포함
      • 하드 정보, 도커 컨테이너 동작 상태 등
    • 쿠버네티스 상태 정보 포함
    • api에 워크노드 정보 제공
  • kube-apiserver
    
    • k8s API를 사용하도록 요청을 받고 요청이 유효한지 검사
    • 모든 요청을 관리
  • kube-scheduler
    • 파드를 실행할 노드 선택
  • kube-controller-manager
    • 파드를 관찰하며 개수를 보장
      • 기존 컨테이너 동작 중인 파드 다운시 다른 파드에서 동작할 수 있게 api에 요청
  • CoreDNS
    • 애드온 프로그램
• 워커 노드 컴포넌트
  • kubelet
    • 모든 노드에서 실행되는 k8s 에이전트
    • 데몬 형태로 동작
    • cAdvisor 컨테이너 모니터링 툴이 포함됨
      • 컨테이너, 하드 상태 정보 수집
  • kube-proxy
    • k8s의 network 동작을 관리
    • iptables rule을 구성
    • 실제 컨테이너를 실행해주는 역할
  • 컨테이너 런타임
    • 컨테이너를 실행하는 엔진
    • docker, containerd, runc
• 애드온 프로그램
  • 네트워크 애드온
    • CNI(Container network interface
      • 네트워크 간 통신 지원
      • weave, calico, flaneld, kube-route 등
  • dns 애드온
    • coreDNS
  • 대시보드 애드온
    • 웹 UI
    • 쿠버네티스 전체 관리
  • 컨테이너 자원 모니터링
    • cAdvisor
  • 클러스터 로깅
    • 컨테이너 로그, k8s 운영 로그들은 수집해서 중앙화
      • 마스터 노드 여러개, 워크 노드 여러개인 경우
    • ELK(ElasticSearch, Logstash, Kibana), EFK(ElasticSearch, Fluentd, Kibana), DataDog 

Reference

따배쿠6강

command 살펴보기

• command 정보
  • kubectl --help
    • command 정보 표시
  • kubectl [command] --help
    • 해당 command 설명
    • 예시 및 옵션 정보 또한 제공
• object 정보
  • kubectl api-resources
    • object 정보(목록, 약어 등) 표시

• 노드 정보
  • kubectl get nodes
    • 노드 정보
  • kubectl get nodes -o wide
    • 노드 정보 상세히
  • kubectl describe node [name]
    • 해당 노드의 더욱 상세한 정보

 

여러 방법으로 nginix pod 생성하기

run으로 pod 생성

• pod 생성
  • kubectl run webserver --image=nginx:1.14 --port 80
    • run은 컨테이너 하드를 만드는 command
    • webserver라는 이름의 pod 생성
    • nginx:1.14의 도커 이미지 다운로드
    • 포트 80번 연결

• pod 생성 확인
  • kubectl get pods
  • kubectl get pods -o wide 
  • kubectl describe pod webserver

• pod 정보 다양한 형태로 확인
  • kubectl get pod webserver -o yaml
  • kubectl get pod webserver -o json
• web server 동작 확인
  • curl 10.44.0.1
    • curl은 command 형식의 웹 브라우저

• web server 이름 바꾸기
  • 컨테이너에 접속
    • kubectl exec webserver -it -- /bin/bash
      • exec는 실행하는 command
  • 컨테이너 안에서 index.html 파일을 찾아 제목 수정
    • cd /usr/share/nginx/html/
    • cat index.html
    • echo "SMLEE web" > index.html
    • exit
  • 컨테이너에서 나와 web server 접속하여 이름 확인
    • curl 10.44.0.1

• webserver 로그 확인
  • kubectl logs webserver

• webserver 포트 포워딩
  
  • kubectl port-forward webserver 8080:80

create으로 deployment 생성

• deployment 생성 
  • kubectl create deployment mainui --image=httpd:latest --replicas=3
    • create deployment는 컨테이너 하드를 여러 개 생성하는 command
    • mainui라는 이름의 deployment 생성
    • replicas는 hpptd라는 웹 서버 3개 실행을 요청하는 옵션

• deployment 생성 확인
  • kubectl get deployments.apps
  • kubectl get deployments.apps-o wide
  • kubectl describe deployments.apps mainui

• pod 생성 확인
  • kubectl get pods
  • kubectl get pods -o wide 

• main ui pod 중 하나의 pod web server 동작 확인
  • curl 10.36.0.1

• 컨테이너 하드 개수 조절하기
  • kubectl edit deployments.apps mainui
    • edit command는 동작 중인 api 리소스를 수정할때 사용
    • vi에디터에서 replicas 수정

 

yaml파일로 pod 생성

• yaml파일 생성
  • kubectl run webserver --image=nginx:1.14 --port 80 --dry-run -o yaml > webserver-pod.yaml
    • webserver pod는 이미 존재하므로 kubectl run webserver --image=nginx:1.14 --port 80 실행 x
    • --dry-run로 실행이 되는지 안되는지 체크
    • --dry-run -o yaml로 실행할 수 있는 상태를 yaml 포맷으로 표기
    • --dry-run -o yaml > webserver-pod.yaml로 yaml파일로 저장

• webserver pod 삭제 
  • kubectl delete pod webserver

• yaml파일로 pod 생성
  • kubectl create -f webserver-pod.yaml

• pod 생성 확인
  • kubectl get pods

Reference

따배쿠5강

kubectl이란?

• 쿠버네티스에게 원하는 것을 요청하는 명령어
  • 명령어의 포맷에 맞춰 '웹 서버 3개 실행해줘'와 같이 요청함

kubectl 명령어 구조

• 기본 구조
  • kubectl [command] [TYPE] [NAME] [flags]
  • ex) kubectl get pod webserver -o wide
• Command
  • 자원(object)에 실행할 명령
  • create, get delete, edit 등
• TYPE
  • 자원의 타입
  • node, pod, service 등
• NAME
  • 자원의 이름
  • 의미를 이해할 수 있는 적절한 이름 설정
  • 소문자, 숫자, _ 이용
• flags
  • 부가적으로 설정할 옵션
  • --help, -o options 등

kubectl 명령어 자동 완성

• kubectl은 tab키를 이용한 자동 완성 기능 지원 x
• tab키를 쓰기 위해 bash shell에 기능 추가 필요
• BASH

source <(kubectl completion bash)
source <(kubeadm completion bash)

echo "source <(kubectl completion bash)">> ~/.bashrc
echo "source <(kubeadm completion bash)">> ~/.bashrc

kubectl commands

• kubectl --help
• kubectl command --help

• kubectl run <자원이름> <옵션>
• kubectl create -f obj.yaml
  • 파일을 불러들여와 오브젝트를 생성
• kubectl apply -f obj.yaml

• kubectl get <자원이름> <객체이름>
  • 오브젝트를 가져와서 출력
• kubectl edit <자원이름> <객체이름>
• kubectl describe <자원이름> <객체이름>
• kubectl explane <객체이름>
  • 리소스의 정보(Documentation) 출력

• kubectl delete pod main

Reference

따배쿠 4강

쿠버네티스 클러스터를 직접 구성하는 도구

• kubeadm
  • 쿠버네티스에서 공식 제공하는 클러스터 생성/관리 도구
• kubespray
  • 쿠버네티스 클러스터를 배포하는 오픈소스 프로젝트
  • 다양한 형식으로 쿠버네티스 클러스터 구성 가능
  • 온프레미스에서 상용 서비스 컬러스터 운영시 유용
  • 다양한 CNI 제공

CNI (Container Network Interface)

• 컨테이너 간 통신을 지원하는 VxLAN
  • 컨테이너는 각각 ip를 갖고 있고 각 컨테이너 간 통신을 하기 위해서는 CNI 필요
• Pod Network이라고도 부름
• 다양한 종류의 플러그인이 존재
  • 플라넬, 칼리코, 위브넷 등
• CNI를 설치하고 컨테이너 간 통신할 때, 컨테이너가 물리 네트워크와 통신하고 물리 네트워크가 다시 컨테이너와 통신함

쿠버네티스 클러스터 구성

• control plane(master node)
  • 워커 노드들의 상태를 관리하고 제어
• worker node
  • 도커 플랫폼을 통해 컨테이너를 동작하며 실제 서비스 제공

kubeadm을 이용한 쿠버네티스 설치 - 온프레미스

• Docker Install(all system)
• kubernetes install
  • 설치 전 환경 설정
  • kubeadm, kubectl, kubelet 설치
  • control-plane 구성
  • worker node 구성
  • 설치 확인

참고

따배쿠 3강

• 카타코다 쿠버네티스 플레이 그라운드
  • Master, node1이 구성되어 있어 바로 사용 가능
  • 1시간 동안 사용 가능
  • 여러 시나리오, 예제 제공
  • 현재 O'reilly에 인수 됨
• Play with Kubernetes
  • Docker에서 제공
  • Github, Docker hub 계정으로 로그인 가능
  • Master, worker node를 직접 구성한 후 사용 가능
  • 4시간 동안 사용 가능
  • 사용 순서
    • 클러스터 마스터 노드 초기화
    • 클러스터 네트워크 초기화(컨테이너 네트워크 인터페이스 설치)
    • 워크 노드 생성
    • 마스터 노드와 워크 노드 조인
    • 마스터 노드에서 kubectl get nodes 명령어를 통해 확인
• 유용한 단축키
  • Ctrl + L : 터미널 클리어
  • Ctrl + Insert : 복사
  • Shift + Insert : 붙여넣기
• 클라우드 서비스에서 제공하는 쿠버네티스 도구
  • 구글 쿠버네티스 엔진(GKE)
  • 아마존 쿠버네티스 일래스틱 컨테이너 서비스(EKS)
  • 애저 쿠버네티스 서비스(AKS)
  • 유료 사용임

참고

따배쿠 2강

컨테이너와 도커

• 컨테이너란?
  • 앱을 실행할 수 있는 가상 공간
• 도커란?
  • 컨테이너를 실행하는 플랫폼
• 사용 방법
  • 컨테이너 생성
    • Linux 운영체제에 도커 설치
    • 도커에 컨테이너 빌드
    • 하드디스크에 이미지 생성
    • 컨테이너(이미지) 도커 허브에 Push
  • 이미지 사용
    • Linux 운영체제에 도커 설치
    • 컨테이너(이미지)허브에서 다운로드
    • 하드디스크에 이미지 생성
    • 컨테이너 실행

가상머신 vs 컨테이너

가상머신

• 동작 순서
  • 하드웨어 인프라에 하이퍼바이저(vmware, virtualbox) 설치
  • 소프트웨어 기술을 이용하여 가상 머신 생성
    • 가상 머신 내 하드웨어 생성(메모리, cpu, network 등)
    • os 설치
• 특징
  • 가장 적합한 하드웨어 리소스 할당(유연한 사용 가능)
    • 세일 등의 이벤트로 추가 리소스 필요한 경우 추가로 할당하여 사용
  • 리소스를 수직적으로 할당하지 않고 수평적으로 할당하는 추세
    • 하나의 가상머신에 추가 리소스를 계속 할당하는 경우 해당 가상머신이 다운되면 서비스 불가

컨테이너

• 동작 순서
  • 하드웨어 인프라에 호스트 운영체제(리눅스, 윈도우 등) 설치
  • 도커 플랫폼 설치&실행
  • 컨테이너 생성
• 특징
  • 컨테이너는 가상머신과 달리 하드웨어, 운영체제 없이 애플리케이션(웹 서버, 웹 콘텐츠)만 있으므로 훨씬 가볍고 확장이 용이
  • 컨테이너는 주로 배포의 목적을 가짐

컨테이너 동작 구조

• 도커 플랫폼에서 여러 컨테이너를 동작하는 구조
  • 웹 서버에 리소스가 많이 필요한 경우 여러 웹 서버 수평적 운영
• 멀티호스트 도커 플랫폼
  • 시스템 자체가 다운된 경우 서비스가 불가능하므로 여러 시스템에 컨테이너를 분산하여 운영하는 구조
    • 여러 시스템에 분산하여 운영하면 하나의 시스템이 다운되어도 다른 시스템을 이용하여 정상 동작 가능

컨테이너 오케스트레이션

• 컨테이너의 애플리케이션들을 웹 서비스에 적합하게 잘 배치하여 최적으로 운영
  • 웹 서버 하나를 운영하는데 수백, 수천개의 컨테이너 사용
  • 엔지니어가 시스템의 컨테이너 분산을 직접 다 관리하는것이 거의 불가능
• control plane에서 work node 관리
  • 다른 시스템들의 애플리케이션 컨테이너들을 배치하고 확장 축소

쿠버네티스

• 쿠버네티스란?
  • k8s라고 작성
    • kubernetes, k와 s사이 8개의 글자
  • 컨테이너화 된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템
  • 쿠버네티스 뜻: 조타수
    • 컨테이너를 운영한다는 의미
  • 구글에서 개발
  • CNCF 재단에 기부
• 특징
  • 워크로드 분리
    • 컨테이너를 분리하여 운영함에도 불구하고 컨테이너 간 통신 원활
  • 어디서나 실행 가능
    • 온프레미스
    • 퍼블릭 클라우드(AKS, EKS, GKE 등)
  • 선언적 API
    • 쿠버네티스 운영자가 웹서버 3개 실행하라고 선언하면 쿠버네티스가 알아서 배치하고 운영

참고

따배쿠 1강

회사에서 진행하는 여러 스터디 중 웹 서비스가 어떻게 운영이 되는지 알기 위해서 쿠버네티스를 배우면 좋겠다는 생각이 들어 쿠버네티스 스터디에 참여하게 되었다.

스터디의 최종 목적은 자격증을 취득하는 것이며 이를 위해 따배쿠 강의를 이용하여 개념을 잡고 예제를 풀며 실습을 한뒤 자격증을 도전하는 프로세스로 구성되어 있었다.

따배쿠 강의는 총 36개 강의로 구성되어 있고 한주에 6개씩 총 6주동안 진행하고 강의를 들으며 학습하고 요약한 내용을 블로그로 공유하려 한다.

이번 시간에는 neo4j의 Multi label기능과 유사한 AgensGraph의 Label 상속에대해 다뤄보도록 한다.

Multi-label은 말그대로 하나의 노드에 여러개의 레이블을 부여하는 것을 의미한다. 이와 유사하게 Label 상속은 부모 레이블에 자식 레이블을 상속시켜 노드에 여러개의 레이블을 상속할 수 있다.

레이블을 상속하는 코드는 다음과 같다.

CREATE VLABEL childVlabelName inherits (parentVlabelName);
CREATE ELABEL childElabelName inherits (parentElabelName1, parentElabelName2);

위에서 inherits()는 자식 레이블을 상속하는 명령이다. 레이블을 생성할 때 레이블 이름 뒤에 해당 키워드와 함께 부모 레이블의 이름을 명시하면 레이블을 상속할 수 있다. 여기서 부모 레이블은 여러개가 될 수 있다.

Example

간단한 예시를 통해 레이블 상속을 이해해보도록 한다.

위와 같이 이름이 초코인 강아지와 나비인 고양이를 '동물'이라는 레이블에 상속시키도록 한다.

create vlabel 동물;
create vlabel 강아지 inherits (동물);
create vlabel 고양이 inherits (동물);

create (v:강아지 {이름:'초코'});
create (v:고양이 {이름:'나비'});

먼저 부모 레이블인 '동물'을 생성하고 자식 레이블인 '강아지', '고양이'를 '동물'레이블에 상속시키며 생성한다. 그리고 각 '강아지', '고양이' 레이블에 이름이 초코, 나비인 노드를 생성해준다.

결과를 확인해 보면 강아지 레이블에는 '초코', 고양이 레이블에는 '나비', 동물 레이블에는 둘 다 포함되어 있음을 알 수 있다.

이번 시간에는 레이블을 상속하는 방법에 대해 알아보았다.

레이블 상속은 잘 활용하면 복잡한 관계에서 다양하고 효율적인 그래프 모델링이 가능할 것이라 생각된다. 따라서, 추후에 활용방안을 더 고민하고 학습해보고 포스팅을 통해 공유해보도록 하겠다.

참고

https://bitnine.net/ko/documentation/ (아젠스그래프 개발자 메뉴얼 가이드)