반응형

kubectl 명령어 정리 배경

  • 자주 쓰는 것들을 정리해둔 내용인데, 혹시 누군가에게 도움이 될까봐 올려둔다.
  • 개인적인 팁은 kubectl 을 k 라는 alias 로 설정해서 쓰면 편하다
  • 쿠버네티스 리소스 관리 유틸리티인 k9s 를 쓰면 더 편리 할 수 있다. (  URL - https://k9scli.io/ )

 

 

kubectl 명령어 모음

# 네임스페이스 생성
$ kubectl create namespace argocd

# 네임스페이스 를 지정하여 yaml 적용하기
$ kubectl apply -n argocd -f argo-cd.yaml



# 포트 포워드 터널링
$ kubectl port-forward svc/서비스이름 [로컬 포트 : 서비스 포트]

$ kubectl port-forward svc/argocd-server -n argocd 8080:80
$ kubectl port-forward --namespace=ingress-nginx service/ingress-nginx-controller 8080:80


# 이벤트 및 파드 로깅
$kubectl get events

$kubectl get ing

$kubectl get svc,pod,ing


# 애플리케이션 로깅
$ kubectl logs -n [네임스페이스] deployment.apps/파드이름
$ kubectl logs -n airflow deployment.apps/airflow-webserver

# 서비스 어카운트 정보 
$ kubectl get sa
$ kubectl get sa -n kube-system
$ kubectl describe sa [] -n []


# yaml 형식으로 출력하기
$kubectl get sa ebs-csi-controller-sa -n kube-system -o yaml >> sa.yaml

$ kubectl get po -A
# A 옵션을 주면 네임스페이스 전체에 있는 파드가 다 뜬다.


# 파드 서비스 진입
$ kubectl exec [파드이름] /bin/sh
$ kubectl exec [파드이름] -it -- bash
# ssh 진입
$ kubectl exec bdp-web-7849b96cf5-2xzlq -n airflow -it -- bash


# watch를 이용한 모니터링
$ watch -d kubectl get deploy, svc, pods

 

 

kubectl alias 설정

$echo "alias k='/home/ec2-user/bin/kubectl'" >> ~/.bash_profile

$ source ~/.bash_profile
반응형
반응형

1.이슈 내용

  • 최근 EMR Cluster 에서 도커 이미지를 이용해 Spark - submit 실행하는 job 을 추가함.
  • 테스트 시에는 문제가 되지 않았으나, 새벽 배치에서 장애 발생

2.장애 또는 에러 내용

  • Docker inspect command : /usr/bin/docker inspect —format {{.State.ExitCode}} container_iD_appid_…..
  • Exit code from docker inspect : 1

3.이슈 원인

  • EMR 에서 Scale Out 시 Task 노드를 임의로 할당 받게 된다. (Spot instance 사용 중)
  • Task 노드의 커널 아키텍쳐가 이미지 내 빌드된 프로세서 아키텍쳐와 호환이 안될 가능성이 있다.
    • 내가 amd64 아키텍쳐로 빌드를 했는데 실제로 arm64 아키텍쳐의 노드 위에서 실행 될 경우..
  • docker inspect 는 실행 전 이미지를 검사하는 단계로 보여진다. 

4.해결방법

  • buildx 를 이용하여 멀티 프로세서 아키텍쳐에 맞게 빌드한다.
  • 참고로 buildx 를 이용할 때 빌드와 push 만 가능하다.
1. buildx 활성화 및 확인
$ docker buildx version
$ docker buildx ls

2. buildx 초기화 및 빌더 인스턴스 생성
$ docker buildx create --name multi-archi-builder
$ docker buildx use multi-archi-builder


$ docker buildx inpsect --bootstrap 
-- bootstrap 은 초기화 프로세스 플래그

3. build 와 동시에 push 하기
$ docker buildx build --platform linux/arm64,linux/amd64 -t myapp:latest --push .

4. 이미지 확인하기
$ docker manifest inpsect [이미지]:[태그]
 

5.회고

- 사실 aws 코리아 기술자 분들과 미팅을 하면서,쿠버네티스 환경에서는 꼭 컨테이너 이미지의 멀티 아키텍쳐 빌드가 필요하다는 내용을 팁으로 들었었다. 그때는 잘 끄덕였는데.. 귀로만 흘려들었더니, 새벽 4시에 일어나 장애 대응을 해야 했던 결과를 맞았다.

최근 배치 장애도 잦고, 더 꼼꼼해야 겠다. 그리고 반성하자

반응형
반응형

1.목표 (what & why)

  • fast 를 이용해본다
  • 유지보수와 확장 가능한 구조의 프로젝트 구조를 만든다.
  • 쿠버네티스 기반 컨테이너 서비스로 동작하도록 만든다.
  • fast api application   
    • 별도 SMTP 서버로 이메일 전송을 대신할 수 있는 api 서버 구현 ( 상세한 구현 로직은 포함하지 않음. )
    • 인증은 기본 토큰 방식을 사용한다.
  • 만드는 목적과 이유
    • 보통 이런 REST API + Application 실행 요구사항은 AWS 람다를 대부분 이용했다. 그리고 이용하면 편하고..
    • AWS 람다는 서버리스기반으로 실행되기 때문에 고정 IP 를 부여하기 힘들다. (서브넷의 CIDR 를 조정하면 될것 같긴 하지만 그렇게는 아무도 안할 것 같다)
    • 화이트 리스트로 등록되어야만 실행을 하게 하는 서비스 들이 있다. 예를 들어 SMTP 서비스 들. 

 

2.과정 (Step)

  • fastapi application 을 작성한다
  • Dockerfile 을 작성하고 컨테이너 이미지를 생성한다
  • 쿠버네티스 Deployment yaml 을 작성하고, 파드, 서비스를 작성한다.
  • 배포와 자동화 스크립트를 만들어본다.
  • 사전 준비 과정
    • Docker , 쿠버네티스, 파이썬 개발 환경의 준비가 되어있어야 한다.

 

3. 방법 (How)

fastapi application 작성한다.

- github  -https://github.com/jaysooo/service-common-api

 



 

Dockerfile 을 작성하고 컨테이너 이미지를 생성한다

from python:3.11-alpine

# set env
WORKDIR /usr/src
# source copy
COPY ./app ./app

ENV PYTHONPATH /usr/src/app

# package install
RUN pip install --upgrade pip && pip install --no-cache-dir -r ./app/requirements.txt

EXPOSE 9000

# container execution
CMD python -m uvicorn app.main:app --reload --host=0.0.0.0 --port 9000

 

이미지 생성과 실행 테스트를 해본다.

#!/bin/bash
echo "[LOG] 01. local deploy.."
IMAGE_NAME=demoapp
IMAGE_VERSION=1.0
TARGET_PORT=9000
#echo ${IMAGE_NAME}:${IMAGE_VERSION}


echo "[LOG] 02. container cleansing.."
docker stop `docker ps | grep -e "${IMAGE_NAME}:${IMAGE_VERSION}" | awk '{print $1}'`
docker rmi -f ${IMG_NAMME}:${IMAGE_VERSION}

echo "[LOG] 03. image build.."
docker build -t ${IMAGE_NAME}:${IMAGE_VERSION} .

echo "[LOG] 04. container run.."
docker run -p ${TARGET_PORT}:${TARGET_PORT} -d ${IMAGE_NAME}:${IMAGE_VERSION}

docker ps | grep -e ${IMAGE_NAME}

 

이미지 빌드 및 실행 화면

 

 

API 실행 화면

 

반응형
반응형

1. 쿠버네티스란?

  • 오픈 소스 플랫폼
  • 오케스트레이션 시스템
  • 컨테이너화된 워크로드와 서비스를 관리

는 공식 홈페이지에 소개 내용이지만, 내가 이해한 내용은 이렇다.

  • 런타임 의존성과 함께 애플리케이션을 패키징하는 컨테이너를 많이 쓰기 시작한다. -> 컨테이너 런타임을 지원하면 어디에서 실행하던 동일한 동작을 보장하니까
  • 하지만 컨테이너는 변경이 불가하다. 즉 애플리케이션의 업데이트가 발생하면 새로 이미지를 빌드 해야 한다.
  • 쿠버네티스는 이러한 경우 서비스 중단 없이 업데이트를 가능하게 해주고, 이 밖에 운영 측면의 스케일링, 리소스 관리 등을 해주는 녀석이다.

2. 왜 쿠버네티스를 사용하지?

  • high Availability = no downtime
  • Scalability
  • High Performance
  • Disaster recovery

위 장점때문에 사람들이 많이 사용하는 것 같은데 구성이 멀티 클러스터로 되어있기 때문이라고 생각한다면 저 장점을 더 이해하기 쉬울 것 같다.

 

3. 쿠버네티스 아키텍쳐

  •  
  • 일반적인 쿠버네티스 배포 → 쿠버네티스 클러스터 생성
  • 쿠버네티스 클러스터
    • 모든 클러스터는 최소 한 개의 워커 노드, 1개의 마스터 노드를 가짐
    • 워커 노드
      • 동작중인 파드를 유지시키고, 쿠버네티스 런타임 환경을 제공하며 모든 노드 상에서 동작
    • 컨트롤 플레인 = 마스터 노드
      • 워커노드와 클러스터 내 파드를 관리한다
      • 컨트롤 플레인이 여러 컴퓨터에 걸쳐 실행되고, 클러스터는 여러 노드를 실행하므로 내결함성과 고가용성이 제공됨

 

컨트롤 플레인

  • 주요 컴포넌트
    • kube-apiserver
      • 쿠버네티스 컨트롤 플레인의 프론트 엔드
      • UI, API, CLI 를 제공
    • etcd
      • 모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소
      • 키-벨류 저장소
      • kubernetes backking stroe
    • kube-scheduler
      • 노드가 배정되지 않은 새로 생성된 파드를 감지
      • 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트
      • ensure pods placement
      • 서버의 리소스또한 감지한다. 몇번 노드에서 메모리 30% 쓰고 뭐 이런 정보들
    • kube-controller-manager ( cm )
      • 컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트
      • 4가지 구성요소
        • 노드 컨트롤러: 노드가 다운되었을때 통지와 대응에 관한 책임
        • 레플리케이션 컨트롤러 : 시스템의 모든 레플리케이션 컨트롤러 오브젝트에 대해 알맞은 수의 파드들을 유지시켜주는 책임
        • 엔드포인트 컨트롤러 : 엔드포인트 오브젝트를 채움 ( 서비스와 파드 연결 )
        • 서비스 어카운트 & 토큰 컨트롤러 : 새로운 네임스페이스에 대한 기본 계정과 api 접근 토큰을 생성
        • keeps track of whats happening in the cluster
    • cloud-contgroller-manager (ccm)
      • 클라우드 별 컨트롤 로직을 포함하는 쿠버네티스 컨트롤 플레인 컴포넌트
      • 3가지 구성요소
        • 노드 컨트롤러 : 노드가 응답을 멈춘 후 클라우드 상에서 삭제되었는지 판별하기 위해 클라우드 제공 사업자에게 확인
        • 라우트 컨트롤러 : 기본 클라우드 인프라에 경로를 구성하는 것
        • 서비스 컨트롤러 : 클라우드 제공 사업자 로드밸런서를 생성, 업데이트, 그리고 삭제 하는 것

워커 노드

  • 주요 컴포넌트
    • kubelet
      • 클러스터 각 노드에서 실행되는 에이전트
      • 파드에서 컨테이너가 동작하도록 관리
    • kube-proxy
      • 클러스터의 각 노드에서 실행되는 네트워크 프록시
      • 노드의 네트워크 규칙을 유지 관리
    • 컨테이너 런타임
      • 컨테이너 실행을 담당하는 소프트 웨어
      • 컨테이너 런타임 인터페이스를 구현한 모든 소프트웨어 지원
반응형

+ Recent posts