모험하는 개발자

[Jenkins] 젠킨스로 CI/CD 구현하기

2021-12-20T00:00:00+00:00

5.4 젠킨스로 CI/CD 구현하기

쿠버네티스 환경에서 젠킨스를 이용하여 CI/CD 환경을 구성해 보자.
CI란 ? (5-1에서 설명했지만 복습을 위해 다시 설명)
- 코드를 커밋하고 빌드했을 때 정상적으로 작동하는지 반복적으로 검증해 애플리케이션의 신뢰성을 높이는 작업
CD란 CI과정에서 생성된 신뢰할 수 있는 애플리케이션을 실제 상용 환경에 자동으로 배포하는 것을 의미.
젠킨스에서 아이템 이란?
- 새롭게 정의할 작업을 의미.
- 이러한 아이템(작업)의 정의와 순서를 모아 둔 전체 작업을 프로젝트라고 한다.
- Freestyle project
  - 자유도가 높은 방식으로, 브라우저에서 사용자가 직접 설정값과 수행할 동작을 입력할 수 있다.
- Pipeline
  - 젠킨스에서 지원하는 고유의 Pipeline 문법으로 코드를 작성해 작업을 정의할 수 있다.
- Multi-configuration project
  - 하나의 소스 코드를 여러 조건의 조합으로 나온 경우의 수에 해당하는 환경에 동시에 배포할 수 있다.
- Folder
  - 젠킨스의 작업이 많아질 수록 폴더를 이용하여 작업을 분류할 수 있다.
- Multibranch Pipeline
  - 하나의 소스 코드 저장소 내에 존재하는 각 브런치에서 파이프라인 코드가 작성된 파일을 불러와 한번에 여러 브런치에 대해 품질 검증, 테스트, 빌드 등의 작업을 할 수 있도록 해준다.

[Nas] 시놀로지 NAS Let’s Encrypt Root 인증서 교체

2021-12-06T00:00:00+00:00

시놀로지 정식 버전이라면 문제가 되지 않지만, 헤놀로지를 사용하는 유저라면 Let’s Encrypt 로 인증서 교체 시

Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 60

위 에러 문구로 교체가 되지 않을 것이다. 아마 CURL 로 접근 시 사용하는 root 인증서가 업데이트가 되면서, 헤놀로지에서는 오래된 인증서로 인해 접근이 되지 않는듯 하다. 따라서 아래와 같은 절차가 필요하다.

https://letsencrypt.org/certs/isrgrootx1.pem.txt 에 접근하여 인증서 내용 복사
/etc/ssl/certs/ca-certificates.crt 파일 맨 아래에 복사한 내용 추가

[Jenkins] 젠킨스 설치 및 설정하기

2021-12-06T00:00:00+00:00

5.3 젠킨스 설치 및 설정하기

5.3.1 헬름으로 젠킨스 설치하기

# helm 저장소 추가
helm repo add jenkins https://charts.jenkins.io

# helm config 다운로드
helm inspect values jenkins/jenkins > jenkins.yaml

controller:
  adminUser: "admin" # 젠킨스 로그인 아이디
  adminPassword: admin # 젠킨스 로그인 패스워드
  ingress:
    ...
    enabled: true
    apiVersion: "networking.k8s.io/v1"
    ...
    annotations:
      kubernetes.io/ingress.class: nginx  
    ...
    hostName: <Worker Node Ip의 hostName>

persistence:
  enabled: true
  storageClass: nfs-standard
  accessMode: "ReadWriteOnce"
  size: "8Gi"

# 설치
kubectl create ns jenkins
kubens jenkins
helm install jenkins -f jenkins.yaml jenkins/jenkins

5.3.2 젠킨스 살펴보기

젠킨스 접속하기

jenkins.yaml 에서 설장했던 hostName 으로 접속
adminUser, adminPassword 에 설정했던 아이디 패스워드로 로그인

5.3.3 젠킨스 컨트롤러 설정하기

젠킨스 시스템 설정하기

젠킨스 관리 > 시스템 설정 메뉴로 이동
젠킨스 시스템 설정 이 현재 접속한 컨트롤러의 설정을 의미

젠킨스 플러그인 관리하기

젠킨스 관리 > 플러그인 관리 메뉴로 이동
이곳에서는 플러그인 설치 가능 목록, 설치 된 목록, 프록시 서버 설정 등을 할 수 있다.

5.3.4 젠킨스 에이전트 설정하기

젠킨스 노드 관리

젠킨스 관리 > 노드 관리 메뉴로 이동
신규 노드
- 에이전트 노드를 추가
Configure Clouds
- 클라우드 환경 기반의 에이전트를 설정할 때 필요
Node Monitering
- 각 종 모니터링 관련된 사항을 설정
노드 목록
- 현재 구성된 노드의 목록을 확인할 수 있다.

쿠버네티스에서 젠킨스 에이전트 구성

Configure Clouds 메뉴로 이동
Kubernetes
- 쿠버네티스 설정과 관련된 영역으로 Name에 이름을 지정할 수 있다.
Kubernetes Cloud details
- 쿠버네티스 클러스터에 접속하기 위한 정보를 설정할 수 있다.
Pod Templates
- 에이전트로 사용할 파드와 관련된 설정을 한다.
- 젠킨스 컨트롤러를 다시 시작하면 모든 설정이 초기화 된다.

jenkins 서비스 어카운트를 위한 권한 설정하기

# jenkins 계정에 쿠버네티스 클러스터에 대한 admin 권한을 부여한다.
kubectl create clusterrolebinding jenkins-cluster-admin \
--clusterrole=cluster-admin --serviceaccount=default:jenkins

jenkins 서비스 어카운트를 통해 젠킨스 에이전트 파드를 생성하거나 젠킨스 에이전트 파드 내부에서 쿠버네티스의 오브젝트에 제약 없이 접근하려면 cluster-admin 역할을 부여해야 한다.

명령	설명
kubectl create	오브젝트를 생성하는 kubectl 명령어
clusterrolebinding	생성되는 오브젝트가 clusterrolebinding임을 나타낸다.
jenkins-cluster-admin	clusterrolebinding으로 생성되는 오브젝트의 이름이 jenkins-cluster-admin임을 나타낸다.
–clusterrole=cluster-admin	clusterrolebinding의 첫 번째 옵션으로, cluster-admin 역할을 부여한다.
–serviceaccount=default:jenkins	clusterrolebinding의 두 번쨰 옵션으로, default에 있는 jenkins라는 서비스 어카운트에 이 권한을 부여한다.

# clusterrolebinding에 적용 된 내용을 yaml으로 출력
kubectl get clusterrolebindings jenkins-cluster-admin -o yaml

[Jenkins] 지속적 통합과 배포 자동화, 젠킨스

2021-11-24T00:00:00+00:00

5 지속적 통합과 배포 자동화, 젠킨스

4장에서 진행한 과정을 파이프라인이라고 한다.
자동화는 크게 지속적 통합(CI), 지속적 배포(CD) 2가지로 정의 된다.

5.1 컨테이너 인프라 환경에서 CI/CD

컨테이너 인프라 환경에서는 주로 CD를 강조하지만 CI와 CD는 함께 사용되기 때문에 개념을 정확히 이해하는 것이 중요하다.
인프라 관점에서 정리한다면, 개발자가 소스를 커밋하고 푸시하면 CI 단계로 들어 가게 되고, 자동 빌드 되고 테스트를 거쳐 배포할 수 있는 애플리케이션인지 검증을 거치면 CD 단계로 넘어간다, CD단계에서는 애플리케이션을 컨테이너 이미지로 만들어서 파드, 디플로이먼트, 스테이트풀셋 등 다양한 오브젝트 조건에 맞춰 배포 된다.

5.1.1 CI/CD 도구 비교

팀시티
- 코틀린 기반으로, 에이전트 3개와 빌드 작업 100개를 무료로 사용할 수 있으며, 이후는 유료 결제를 해야 한다.
깃허브 액션
- 깃허브에서 지원하는 워크플로 기반의 도구이다. 한달에 2,000분 제한 시간이 있으며, 추가로 사용할 경우 분 단위의 요금이 부과 된다.
뱀부
- 아틀라시안에서 만든 도구로, 유료이며, 사용자 서버에 설치해 사용한다. 아틀라시안에서 만든 다른 협업 도구를 사용 중이라면 같이 사용하기 좋다.
젠킨스
- 오픈 소스 도구로, 사용자가 직접 UI에서 작업을 구성하거나 코드로 정의할 수 있다.
- 오랜 시간 동안 사용되어 CI/CD 도구의 대명사라 해도 될 정도이다.
- 사용자 수가 많아 정보를 찾기 쉽고 활용 방법과 플러그인 개발 등 쉽게 찾을 수 있다.
따라서 젠킨스로 ㄱㄱ

젠킨스로 쿠버네티스 운영 환경 개선하기

컨테이너 인프라 환경에서 젠킨스를 사용하는 주된 이유는 애플리케이션을 컨테이너로 만들고 배포하는 과정을 자동화 하기 위해서이다.
젠킨스는 컨트롤러와 에이전트 형태로 구성한 다음 배포해야 하며, 여기에 필요한 설정을 모두 넣어야 한다.
구성 환경에 따라 많은 부분을 동적으로 변경해야 하는데, 동적인 변경 사항을 간편하고 빠르게 적용할 수 있도록 도와주는 도구에는 커스터마이즈 그리고 헬름이 있다.

5.2 젠킨스 설치를 위한 간편화 도구 살펴보기

5.2.1 배포 간편화 도구 비교하기

구분	큐브시티엘	커스터마이즈	헬름
설치방법	쿠버네티스에 기본 포함	별도 실행 파일 또는 쿠버네티스에 통합	별도 설치
배포 대상	정적인 야믈 파일	커스터마이즈 파일	패키지(차트)
주 용도	오브젝트 관리 및 배포	오브젝트의 가변적 배포	패키지 단위 오브젝트 배포 및 관리
가변적 환경	대응 힘듬(야믈 수정 필요)	간단한 대응 가능	복잡한 대응 가능
기능 복잡도	단순함	보통	복잡함

5.2.2 커스터마이즈로 배포 간편화하기

커스터마이즈의 작동 원리

야믈 파일에 정의된 값을 사용자가 원하는 값으로 변경할 수 있다.

# 커스터마이즈로 변경될 작업을 정의
kustomize create --namespace=metallb-system --resources namespace.yaml,metallb.yaml,metallb-12config.yaml

kustomization.yaml

resources:
- namespace.yaml
- metallb.yaml
- metallb-12config.yaml
namespace: metallb-system

# 설치 된 이미지를 안정적인 버전으로 유지하기 위해 이미지 태그를 v0.8.2로 지정
kustomize edit set image metallb/controller:v0.8.2
kustomize edit set image metallb/speaker:v0.8.2

kustomization.yaml

[중략]
images:
- name: metallb/controller
  newTag: v0.8.2
- name: metallb/speaker
  newTag: v0.8.2

# MetlLB 설치를 위한 매니페스트를 생성
kustomize build

# 빌드한 결과가 바로 kubectl apply에 인자로 전달돼 배포되도록 할수도 있다.
kustomize build | kubectl apply -f -

# MetalLB가 정상 배포 되었는지 확인
kubectl get pods -n metallb-system
kubectl get configmap -n metallb-system

# 디플로이먼트 1개를 배포하여 LB 타입으로 노출하고 IP가 정상적으로 할당 됬는지 확인
kubectl create deployment echo-ip --image=sysnet4admin/echo-ip
kubectl expose deployment echo-ip --type=LoadBalancer --port=80
kubectl get service echo-ip

5.2.3 헬름으로 배포 간편화하기

헬름의 작동 원리

쿠버네티스에 패키지를 손쉽게 배포할 수 있도록 패키지를 관리하는 쿠버네티스 전용 패키지 매니저이다.

플랫폼	패키지 매니저	저장소	사용 목적
리눅스	yum, apt	배포판 저장소	소프트웨어 의존성 관리
파이썬	pip	pypi.org	파이썬 모듈 의존성 관리
자바	maven	mvnrepository.com	자바 라이브러리의 의존성 관리
쿠버네티스	helm	artifacthub.io	쿠버네티스 패키지 관리

다수의 오브젝트 배포 야믈은 파일 구분자인 ‘---‘로 묶어 단일 야믈로 작성해 배포할 수 있는 장점이 있다.
요구 조건별로 리소르를 편집하거나 변수를 넘겨서 처리하는 패키지를 만들 수 있다. 이 패키지는 차트라고 한다
배포한 애플리케이션을 업그레이드하거나 되돌릴 수 있는 기능과 삭제할 수 있는 기능을 제공한다.

# MetalLB 설치를 위해 저장소 등록
helm repo add edu https://iac-source.github.io/helm-charts

# 레포지토리 업데이트
helm repo update

# 설치
helm install metallb edu/metallb \
--namespace=metallb-system \
--crate-namespace \
--set controller.tag=v0.8.3 \
--set speaker.tag=v0.8.3
--set configmap.ipRange=192.168.1.11-192.168.1.29

# 배포 상태 확인
kubectl get pods -n metallb-system
kubectl get configmap -n metallb-system

# 테스트를 위한 디플로이먼트 생성
kubectl create deployment echo-ip --image=sysnet4admin/echo-ip
kubectl expose deployment echo-ip --type=LoadBalancer --port=80
kubectl get service echo-ip

[Docker] 4가지 방법으로 컨테이너 이미지 만들기

2021-11-20T00:00:00+00:00

4.3 4가지 방법으로 컨테이너 이미지 만들기

4.3.1 기본 방법으로 빌드하기

자바소스 빌드 -> 도커파일 작성 -> 도커파일 빌드 -> 빌드 완료

도커 빌드에 사용 된 Dockerfile은 DSL로 작성된 파일이다.

FROM openjdk:8
LABEL description="Echo IP Java Application"
EXPOST 60431
COPY ./abc.jar /opt/abc.jar
WORKDIR /opt
ENTRYPOINT ["java", "-jar", "abc.jar"]

	도커 파일 내용	배시 명령으로 유사 해석	설명
1	FROM openjdk:8	import openjdk:8 image	openjdk를 기초 이미지로 사용한다.
2	LABEL description=”Echo IP Java Application”	Label_desc=”Echo IP Java Application”	이미지에 부가적인 설명을 위한 레이블을 추가할 떄 사용
3	EXPOST 60431	EXPOST=60431	사용할 포트
4	COPY ./abc.jar /otp/abc.jar	scp ./target/abc.jar /opt/abc.jar	컨테이너 이미지로 필요한 파일 복사
5	WORKDIR /opt	cd /opt	이미지의 현재 작업 위치를 opt로 변경
6	ENTRYPOINT [“java”, “-jar”, “abc.jar”]	./java -jar .abc.jar	abc.jar를 java -jar 명령어를 통해 실행

# 생성한 이미지 확인
docker images basic-img

# 1.0 태그 이미지 생성
docker build -t basic-img:1.0

# sed를 이용한 Dockerfile 내용 중 일부 수정
sed -i 's/Application/Development/' Dockerfile

# 버전이 중복 되지 않도록 태그 2.0 으로 사용
docker build -t basic-img:2.0 .

# 컨테이너 동작
docker run -d -p 60431:80 --name basic-run --restart always basic-img

4.3.2 컨테이너 용량 줄이기

도커파일 작성 -> 도커파일 빌드 -> 빌드 완료

Dockerfile

FROM gcr.io/distroless/java:8 # 자바 실행을 위해 설계 된 가벼운 이미지
LABEL description="Echo IP Java Application"
EXPOST 60432
COPY ./abc.jar /opt/abc.jar
WORKDIR /opt
ENTRYPOINT ["java", "-jar", "abc.jar"]

Dockerfile 에서 변경 된 FROM 에 distroless 는 자바 실행으 위해 경량화 된 이미지이다.

용량을 줄여 빌드한 컨테이너 이미지와 원래 빌드한 이미지를 비교.

# 현재 새로 생성된 이미지만 볼 수 있게 head -n 3 옵션을 추가
docker images | head -n 3
REPOSITORY      TAG     SIZE
optimal-img     latest  145MB
basic-img       latest  528MB

# 정상 작동하는지 확인
docker run -d -p 60432:80 --name optimal-run --restart always optimal-img

4.3.3 컨테이너 내부에서 컨테이너 빌드하기

도커파일 작성 -> 도커파일 빌드 -> 빌드 완료

FROM openjdk:8
LABEL description="Echo IP Java Application"
EXPOST 60433
RUN git clone https://github.com/iac-source/inbuilder.git # 이미지 내부에서 실행하기 위해 RUN을 추가
WORKDIR inbuilder # git clone으로 내려받은 디렉터리 현재 작업 공간으로 설정
RUN chmod 700 mvnw # mvnw에 실행 권한 설정
RUN ./mvnw clean package # 메이븐 래퍼로 JAR 빌드
RUM mv target/abc.jar /opt/abc.jar # 빌드된 jar를 옮김
WORKDIR /opt
ENTRYPOINT ["java", "-jar", "abc.jar"]

# docker 파일 빌드
docker build -t nohost-img

# 정상 작동 확인
docker run -d -p 60433:80 --name nohost-run --restart always nohost-img

# 빌드한 컨테이너 삭제
docker rm -f optimal-run
docker rm -f basic-run
docker rm -f nohost-run

4.3.4 최적화해 컨테이너 빌드하기

도커파일 작성 -> 도커파일 빌드 -> 빌드 완료

멀티 스테이지 빌드은 최종 이미지의 용량을 줄일 수 있고 호스트에 어떠한 빌드 도굴르 설치할 필요도 없다.
docker-ce 17.06 버전 부터 지원한다.

Dockerfile

# 1단계: 자바 소스를 빌드해 JAR로 만든다.
FROM openjdk:8 AS int-build # openjdk 이미지에 별칭을 붙인다.`
LABEL description="Echo IP Java Application"
RUN git clone https://github.com/iac-source/inbuilder.git
WORKDIR inbuilder
RUN chmod 700 mvnw
RUN ./mvnw clean package

# 2단계: 빌드 된 JAR를 경량화 이미지에 복사한다.
FROM gcr.io/distroless/java:8
LABEL description="Echo IP Java Application"
EXPOSE 60434 # 노출 되는 포트의 중복을 피하고자 변경.
COPY --from=int-build inbuilder/target/abc.jar /opt/abc.jar # 1단계에서 빌드가 완성된 jar를 distroless에 복사 함
WORKDIR /otp
ENTRYPOINT ["java", "-jar", "abc.jar"]

docker build -t multistage-img

컨테이너 이미지 중에 으로 표시되는 이미지가 있다, 이런 이미지를 댕글링 이미지라고 한다.

멀티 스테이지 과정에서 자바 소스를 빌드하는 과정에 생성 된 이미지로, 불필요한 이미지이기에 삭제 한다.

docker rmi $(docker images -f danling=true -q)

# 정상 작동 확인
docker run -d -p 60434:80 --name multistage-run --restart always multistage-img

# 그동안 빌드한 컨테이너 삭제
docker rm -f optimal-run
docker rm -f basic-run
docker rm -f nohost-run
docker rm -f multistage-run

[Docker] 쿠버네티스에서 직접 만든 컨테이너 사용하기

2021-11-20T00:00:00+00:00

4.4 쿠버네티스에서 직접 만든 컨테이너 사용하기

4.4.1 쿠버네티스에서 도커 이미지 구동하기

쿠버네티스는 컨테이너를 효과적으로 다루기 위해 만들어 졌다.
kubectl 명령으로 직접 만든 컨테이너 이미지도 구동할 수 있다.

Dockerfile

FROM openjdk:8 AS int-build
LABEL description="Java Application builder"
RUN git clone https://github.com/iac-source/inbuilder.git
WORKDIR inbuilder
RUN chmod 700 mvnw
RUN ./mvnw clean package

FROM gcr.io/distroless/java:8
LABEL description="Echo IP Java Application"
EXPOSE 60434
COPY --from=int-build inbuilder/target/app-in-host.jar /opt/app-in-image.jar
WORKDIR /opt
ENTRYPOINT [ "java", "-jar", "app-in-image.jar" ]

# 내부에 존재하는 컨테이너 이미지를 사용하도록 설정하여 디플로이먼트 생성
kubectl create deployment test --dry-run=client -o yaml \ --image=multistage-img > test.yaml

4.4.2 레지스트리 구성하기

호스트에서 생성한 이미지를 사용하려면 모든 노드에서 공통으로 접근하는 저장소가 필요하다.
도커는 레지스트리에 접속하는 과정에서 주체 대체 이름 이라는 추가 정보를 검증하기 때문에 인증서를 생성하는 과정이 필요하다.
도커에서 제공하는 도커 레지스트리 이미지를 사용하여 사설 도커 레지스트리를 만들어 보자.

tls.csr

[req]
distringuished_name = private_registry_cert_req
x509_extensions = v3_req
prompt = no

[private_registry_cert_req]
C = KR
ST = SEOUL
L = SEOUL
O = gilbut
OU = uluru
CN = 192.16.1.10

[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.0 = uluru
IP.0 = 102.168.1.10

create-registry.sh

#!/usr/bin/env bash
# 레지스트리를 생성 하고 구동하는 과정이 담긴 스크립트이다.
certs=/etc/docker/certs.d/192.168.1.10:8443
mkdir /registry-image
mkdir /etc/docker/certs
mkdir -p $certs
openssl req -x509 -config $(dirname "$0")/tls.csr -nodes -newkey rsa:4096 \ -keyout tls.key -out tls.crt -days 365 -extensions v3_req

yum install sshpass -y
for i in {1..3}
    do
        sshpass -p vgrant ssh -o StrictHostKeyChecking=no root@192.168.1.10$i mkdir -p $certs
        sshpass -p vagrant scp tls.crt 192.168.1.10$i:$certs
    done

cp tls.crt $certs
mvtls.* /etc/docker/certs

docker run -d \
    --restart=always \
    --name registry \
    -v /etc/docker/certs:/docker-in-certs:ro \
    -v /registry-image:/var/lib/registry \
    -e REGISTRY_HTTP_ADDR=0.0.0.0:443 \
    -e REGISTRY_HTTP_TLS_CERTIFICATE=/docker-in-certs/tls.crt \
    -e REGISTRY_HTTP_TLS_KEY=/docker-in-certs/tls.key \
    -p 8443:443
    registry:2

# sh 실행
~/create-registry.sh

# 이미지를 도커 레지스트리에 등록
docker push 192.168.10.10:8443/

4.4.3 직접 만든 이미지로 컨테이너 구동하기

test.yaml

spec:
  containers:
  - image: 192.168.1.10:8443/multistage-img
    name: multistage
    resources: {}
status: {}

# test.yaml 디플로이 먼트 생성
kubectl apply -f test.yaml

# 구동 확인
kubectl get pods -o wide

[Docker] 도커를 알아야 하는 이유

2021-11-11T00:00:00+00:00

4.1 도커를 알아야 하는 이유

쿠버네티스를 이루는 기본 오브젝트가 파드고, 파드는 컨테이너로 이루어져 있으며, 컨테이너를 만들고 관리하는 도구가 도커 이다.

4.1.1 파드, 컨테이너, 도커, 쿠버네티스의 관계

파드들은 워커 노드라는 노드 단위로 관리한다.
워커 노드와 마스터 노드가 모여 쿠버네티스 클러스터가 된다.
파드는 1개 이상의 컨테이너로 이루어져 있다.
파드는 쿠버네티스로부터 IP를 받아 컨테이너가 외부와 통신할 수 있는 경로를 제공한다.
파드는 컨테이너들이 정상적으로 작동하는지 확인하고 너트워크나 저장 공간을 서로 공유하게 한다.
따라서, 컨테이너를 돌보는 것이 파드고, 파드를 돌보는 것이 쿠버네티스 워커 노드이며, 워커 노드를 돌보는 것이 쿠버네티스 마스터이다.

컨테이너는 하나의 운영 체제 안에서 커널을 공유하며 개별적인 실행 환경을 제공하는 격리된 공간이다.
개별적인 실행 환경이란 CPU, 네트워크, 메모리와 같은 시스템 자원을 독자적으로 사용하도록 할당된 환경을 말한다.

도커는 컨테이너를 사용하는 방법을 명령어로 정리한 것으로 보면 된다.

4.1.2 다양한 컨테이너 관리 도구

구분	설명
컨테이너디	1. Docker사에서 컨테이너 런타임 부분을 분리하여 만든 오픈 소스 컨테이너 관리도구이다. 2. 쿠버네티스와의 통신에 필요한 컨테이너 런타임 인터페이스 규격에 맞춰 구현한 플로그인을 사용해 쿠버네티스와 통합할 수 있다.
크라이오	1. 레드햇에서 개발해 2019년 클라우드 네이티브 컴퓨팅 재단에 기부한 오픈 소스 프로젝트이다. 2. 다른 도구보다 가볍고 단순하며, 컨테이너 런타임 인터페이스 규격을 자체적으로 구현하고 있어서 별도의 구성요소나 플러그인 없이 쿠버네티스와 통합할 수 있다.
카타컨테이너	1. 오픈스택 재단에서 후원하는 오픈 소스 컨테이너 관리 도구이다. 2. 컨테이너마다 독립적인 커널을 제공한다는 점에서 기존 컨테이너 방식과 큰 차이가 있다. 3. 카타를 실행하면 개별 컨테이너를 위한 가벼운 가상 머신을 생성하고 그 위에 컨테이너가 작동한다. 4. 모든 컨테이너가 독립적인 커널을 사용하므로 다른 컨테이너의 영향을 받지 않는다.
도커	1. Docker사에서 2013년에 만든 컨테이너 관리 도구로, 컨테이너 관리 기능 외에도 컨테이너를 실행하는 데 필요한 이미지를 만들거나 공유하는 등 다양한 기능을 제공한다. 2. 사용자가 명령어를 입력하는 명령어 도구와 명령을 받아들이는 도커 데몬으로 구성 되어있다.

구분	컨테이너디	크라이오	카타 컨테이너	도커
명령어 도구	별도 지원	타 도구 사용	자체 지원	자체 지원
내부 구조	단순	매우 단순	복잡	복잡
확장성	좋음	좋지 못함	좋지 못함	매우 좋음
컨테이너 관리	좋음	좋음	좋음	매우 좋음
이미지 관리	좋음	좋음	좋음	매우 좋음
보안성	좋음	좋음	매우 좋음	좋음
자원 사용량	매우 좋음	매우 좋음	좋지 못함	좋음
정보량	적음	거의 없음	거의 없음	매우 많음

[Docker] 도커로 컨테이너 다루기

2021-11-11T00:00:00+00:00

4.2 도커로 컨테이너 다루기

4.2.1 컨테이너 이미지 알아보기

이미지 검색하고 내려받기

이미지는 레지스트리라고 하는 저장소에 모여 있다.
레지스트리는 도커 허브처럼 공개된 유명 레지스트리일 수도 있고, 내부에 구축한 레지스트리일 수도 있다.
이미지는 레지스트리 웹 사이트에서 직접 검색해도 되고, 명령 창에서 쿠버네티스 마스터 노드에 접속해 검색할 수도 있다.

# 이미지 검색 Ex) docker search [검색어]
docker search nginx

# 이미지 내려받기 Ex) docker pull [NAME]
docker pull nginx

이미지 태그

태그는 이름이 동일한 이미지에 추가하는 식별자이다.
이미지를 내려받거나 이미지를 기반으로 컨테이너를 구동할 때 태그를 명시하지 않으면 기본 적으로 latest 태그를 사용한다.
최신 버전은 latest, 안정화 버전은 stable

# 최신 버전
docker pull nginx:latest 또는 docker pull nginx
# 안정화 버전
docker pull nginx:stable

이미지의 레이어 구조

컨테이너 이미지는 애플리케이션과 각종 파일을 담고 있다는 점에서 Zip 같은 압축 파일과 비슷하다.
압축 파일은 파일의 개수에 따라 전체 용량이 증가하지만 이미지는 같은 내용일 경우 여러 이미지에 동일한 레이어를 공유하므로 전체 용량이 감소한다.

# 내려받은 이미지 조회 Ex) docker images [NAME]
docker images nginx

# stable 이미지 생성 과정에 대한 자세한 이력을 볼 수 있다.
# 또한 latest 버전과 stable 버전에서 서로 레이어를 공유하고 있음을 확인할 수 있다.
docker history nginx:stable
docker history nginx:latest

4.2.2 컨테이너 실행하기

# 새로운 컨테이너를 실행
docker run -d --restart always nginx

옵션에 따라 달라지는 컨테이너 시작 방법

값	컨테이너 비정상 종료 시	도커 서비스 시작 시
no (기본값)	컨테이너를 재시작하지 않음	컨테이너를 시작하지 않음
on-failure	컨테이너를 재시작함	컨테이너를 시작함
always	컨테이너를 재시작함	컨테이너를 시작함
unless-stopped	컨테이너를 재시작함	사용자가 직접 정하지 않은 컨테이너만 시작함

# 생성한 컨테이너 상태를 확인
docker ps

CONTAINER ID
- 컨테이너를 식별하기 위한 고유 ID
IMAGE
- 컨테이너를 만드는 데 사용한 이미지
COMMAND
- 컨테이너가 생성될 때 내부에서 작동할 프로그램을 실행하는 명령어
CREATED
- 컨테이너가 생성 된 시각
STATUS
- 컨테이너가 작동을 시작한 시각 (CREATED와 달리 컨테이너를 재시작할 경우 초기화)
PORTS
- 컨테이너가 사용하는 포트와 프로토콜
NAMES
- 컨테이너 이름을 표시 (docker run 시에 –name 옵션으로 직접 지정 가능)

# docker ps 시 -f 옵션으로 필터링 할 수 있다. (문자열 포함)
# ex) docker ps -f id=[CONTAINER ID]
docker ps -f id=ef

자주 사용하는 필터링 키

id
- 컨테이너 아이디
name
- 컨테이너 이름
label
- 컨테이너 레이블
exited
- 컨테이너가 종료됬을 때 반환하는 숫자 코드
status
- 컨테이너의 작동 상태
ancestor
- 컨테이너가 사용하는 이미지

컨테이너는 변경 불가능한 인프라를 지향한다.
따라서 초기에 인프라를 구성하면 임의로 디렉터리 연결이나 포트 노출 같은 설정을 변경할 수 없다.
번거롭더라도 컨테이너 설정의 변경이 필요하고자 한다면 새로운 컨테이너를 생성해야 한다.
이러한 특성 덕분에 컨테이너로 배포된 인프라는 배포된 상태를 유지한다는 장점이 있다.

# 컨테이너 외부에서 접속할 수 있도록 포트포워딩을 해준다.
docker run -d -p 8080:80 --name nginx-exposed --restart always nginx

# 지정한 name 을 필터링 하여 컨테이너가 작동하는지 확인
docker ps -f name=nginx-exposed

컨테이너가 정상적으로 동작한다면 외부에서 8080으로 접근 시 해당 컨테이너의 80포트 서비스로 접근할 수 있다.

4.2.3 컨테이너 내부 파일 변경하기

도커는 컨테이너 내부에서 컨테이너 외부의 파일을 사용할 수 있는 방법을 크게 4가지 제공 한다.
docker cp
- 호스트에 위치한 파일을 구동 중인 컨테이너 내부에 복사
- 컨테이너에 임시로 필요한 파일이 있는 경우 또는 컨테이너에 저장돼 있는 설정 및 로그를 추출해 확인하는 목적으로 사용
Dockerfile ADD
- 이미지는 Dockerfile을 기반으로 만들어지는데, Dockerfile에 ADD 라는 구문으로 이미지를 빌드할 떄 지정한 파일이 이미지 내부로 복사 된다.
- 사용자가 원하는 파일을 선택해 사용할 수 없다는 단점이 있다.
바인드 마운트
- 호스트 파일의 시스템과 컨테이너 내부를 연결해 양쪽에 동시에 반영 된다.
- 컨테이너가 바뀌어도 없어지면 안 되는 자료는 이 방법으로 보존할 수 있다.
볼륨
- 바인드 마운트와 비슷하지만, 도커가 관리하는 볼륨을 컨테이너와 연결한다는 점에서 다르다.
- 도커가 관리하는 볼륨 공간을 NS와 같은 공유 디렉터리에 생성 한다면 다른 호스트에서도 도커가 관리하는 볼륨을 함께 사용할 수 있다.
보통 서비스를 하면서 파일을 보존해야 되기 때문에 바인드 마운트 또는 볼륨이 효과적인 방법이다.

구분	docker cp	Dockerfile ADD	바인드 마운트	볼륨
컨테이너 적용	구동 중 복사	이미지 생성 시 복사	구동 시 디렉터리 연결	구동 시 도커의 볼륨 연결
파일 보관 위치	컨테이너 내부	컨테이너 내부	호스트(디렉터리)	호스트(도커 볼륨)
주 활용 용도	임시 파일	컨테이너 생성 시 필요한 파일	보존이 필요한 파일	보존이 필요한 파일
관리 편의성	좋지 못함	좋음	좋음	매우 좋음
파일 보존성	좋지 못함	좋음	매우 좋음	매우 좋음

4.2.4 사용하지 않는 컨테이너 정리하기

docker stop 명령어로 사용하지 않는 컨테이너를 정지할 수 있다.

# 컨테이너를 생성하는 데 사용한 이미지를 기준으로 필터링하여 컨테이너 상태 확인
docker ps -f ancestor=nginx

# -q 옵션으로 컨테이너 ID만 출력 하도록하여 인자에 담아 일괄 정지 처리
docker stop $(docker ps -q -f ancestor=nginx)

컨테이너를 정지를 하였고, 컨테이너를 다시 구동하고 싶다면 docker start <컨테이너 ID> 를 실행 한다.

컨테이너를 삭제 하기 위해서는 docker rm 명령어를 사용 한다.

# -q 옵션으로 컨테이너 ID만 출력 하도록하여 인자에 담아 일괄 삭제 처리
# -a 옵션의 경우 정지 된 컨테이너 상태까지 모두 보여준다.
docker rm $(docker ps -aq -f ancestor=nginx)

컨테이너를 모두 삭제 하였지만, 내려받은 이미지는 아직 남아 있어 공간을 차지 한다. 따라서 사용하지 않는 이미지라면 이미지도 삭제 처리.
```
docker rmi $(docker images -q nginx)
```

[Kubernetes] 쿠버네티스 오브젝트

2021-11-06T00:00:00+00:00

3.4 알아두면 쓸모 있는 쿠버네티스 오브젝트

오브젝트에는 데몬셋, 컨피그맵, PV, PVC, 스테이트풀셋 등 이 있다.

3.4.1 데몬셋

데몬셋은 디플로이먼트의 replicas가 노드 수만큼 정해져 있는 형태라고 할 수 있으며, 노드 하나당 파드 한 개만을 생성한다.
노드를 관리하는 파드라면 데몬셋으로 만드는 게 가장 효율적이다.

데몬셋을 만드는 예제를 보며 작동 원리를 확인해 보자.

# 현재 MetalLB의 스피커가 각 노드에 분포돼 있는 상태를 확인한다.
kubectl get pods -n metallb-system -o wide

# 워커 노드를 추가 후 -w 옵션을 추가하여 실시간으로 오브젝트 상태 변화를 감지한다.
kubectl get pods -n metallb-system -o wide -w

# 자동으로 추가된 노드에 설치된 스피커가 데몬셋이 맞는지 확인.
kubectl get pods [생성 된 스피커 이름] -o yaml -n metallb-system

3.4.2 컨피그맵

컨피그맵은 설정을 목적으로 하는 오브젝트이다.

컨피그맵으로 작성 된 MetalLB의 IP 설정을 변경해 보자.

#테스트용 디플로이먼트를 cfgmap 이라는 이름으로 생성.
kubectl create deployment cfgmap --image=sysnet4admin/echo-hname

#cfgmap을 로드밸런서를 통해 노출하고 이름은 cfgmap-svc 로 지정
kubectl expose deployment cfgmap --type=LoadBalancer --name=cfgmap-svc --port=80

# 생성된 서비스 IP 확인
kubectl get services

# sed 명령을 사용항려 기존 IP를 변경 (11 -> 21, 13 -> 23)
sed -i 's/11/21;s/13/23/' ~/config.yaml

#apply를 실행하여 변경된 설정을 적용
kubectl apply -f ~/config.yaml

# MetalLB와 관련된 모든 파드를 삭제하면 이후에 kubelet에서 해당 파드를 자동으로 모두 다시 생성한다. -all 옵션을 통해 한번에 모두 삭제 할 수 있다.
kubectl delete pods --all -n metallb-system

# 새롭게 생성 된 MetalLB의 파드들을 확인
kubectl get pods -n metallb-system

# 기존에 삭제한 서비스를 동일한 이름으로 다시 생성하여 새로운 컨피그맵을 적용한 서비스가 올라오게 한다.
kubectl delete service cfgmap-svc
kubectl exposd deployment cfgmap --type=LoadBalancer --name=cfgmap-svc --port=80

# 새로 올라온 서비스의 IP가 바뀌었는지 확인.
kubectl get services

3.4.3 PV와 PVC

쿠버네티스는 다음과 같은 목적으로 다양한 형태의 볼륨을 제공한다.

구분	볼륨
임시	emptyDir
로컬	host Path, local
원격	persistentVolumeClaim, cephfs, cinder, csi, fibre channel, flexVolume, flocker, glusterfs, iscsi, nfs, portworkxVolume, quobyte, rbd, scaleIO, storageos, vsphereVolume
특수 목적	downwardAPI, configMap, secret, azureFile, projected
클라우드	awsElasticBlockStore, azureDisk, gcePersistentDisk

PV는 볼륨을 사용할 수 있게 준비하는 단계이고, PVC는 준비된 볼륨에서 일정 공간을 할당받는 것이다. 비유하면 PV는 요리사가 피자를 굽는 것이고, PVC는 손님이 원하는 만큼의 피자를 접시에 담아 가져오는 것이다.

NFS 볼륨에 PV/PVC를 만들고 파드에 연결하기

# 공유할 디렉토리를 생성하고 NFS로 받아들일 IP 영역을 정한다.
mkdir /nfs_shared
echo '/nfs_shared 192.168.1.0/24(rw,sync,no_root_squash)' >> /etc/exports

# NFS 서버를 활성화하고 다음에 시작할때 자동으로 적용 되도록 한다.
systemctl enable --now nfs

# 오브젝트 스펙을 실행하여 PV를 생성
kubectl apply -f ~/nfs-pv.yaml

nfs-pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 100Mi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    server: 192.168.1.10
    path: /nfs_shared

# PV의 상태가 Available(사용가능)임을 확인
kubectl get pv

# 오브젝트 스펙을 실행하여 PVC를 생성
kubectl apply -f ~/nfs-pvc.yaml

nfs-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Mi

# 생성한 PVC를 볼륨으로 사용하는 디플로이먼트 오브젝트 스펙을 배포
kubectl apply -f ~/nfs-pvc-deploy.yaml

nfs-pvc-deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-pvc-deploy
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nfs-pvc-deploy
    template:
      metadata:
        labels:
          app: nfs-pvc-deploy
    template:
      metadata:
        labels:
          app: nfs-pvc-deploy
      spec:
        containers:
        - name: audit-trail
          image: sysnet4admin/audit-trail
          volumeMounts:
          - name: nfs-vol
            mountPath: /audit
        volumes:
        - name: nfs-vol
          persistentVolumeClaim:
            claimName: nfs-pvc

# 생성된 파드를 확인 후 생성한 파드 중 하나에 exec로 접속
kubectl get pods
kubectl exec -it nfs-pvc-deploy-788b77964-69c8n -- /bin/bash

# 외부에서 파드에 접속할 수 있도록 expose로 로드밸런서 서비스를 생성
kubectl expose deployment nfs-pvc-deploy --type=LoadBalancer --name=nfs-pvc-deploy-svc --port=80

# 다른 파드 1개를 추가로 exec로 접속
kubectl exec -it nfs-pvc-deploy-7888b77964-c66nrp -- /bin/bash

이전에 접속한 파드에서 ls /audit 명령어를 통해 audit 로그를 확인하고, 다른 파드에서도 동일하게 ls /audit 명령어를 치고 동일한 로그파일인지 확인.

NFS 볼륨을 파드에 직접 마운트하기

사용자와 관리자가 동일한 단일 시스템이라면 PV와 PVC를 사용할 필요가 없다. 따라서 볼륨을 마운트 해보자.

kubectl apply -f ~/nfs-ip.yaml

nfs-ip.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
name: nfs-ip
spec:
replicas: 4
selector:
  matchLabels:
    app: nfs-ip
template:
  metadata:
    labels:
      app: nfs-ip
  spec:
    containers:
    - name: audit-trail
      image: sysnet4admin/audit-trail
      volumeMounts:
      - name: nfs-vol
        mountPath: /audit
    volumes:
    - name: nfs-vol
      nfs:
        server: 192.168.1.10
        path: /nfs_shared

# 새로 배포된 파드를 확인하고 그중 하나를 exec 로 접속한다.
kubectl get pods
kubectl exec -it nfs-ip-84fd4d6f69-475vb --v /bin/bash

동일하게 양쪽에서 ls /audit 를 실행해 동일한 NFS 볼륨을 바라보고 있는지 확인.

3.4.4 스테이트풀셋

파드가 만들어지는 이름과 순서를 예측해야 할 때가 있다. 주로 레디스, 주키퍼, 카산드라, 몽고DB 등의 마스터-슬레이브 구조 시스템에서 필요하다. 이때 스테이트풀셋을 사용한다.
스테이트풀셋은 volumeClaimTemplates 기능을 사용해 PVC를 자동으로 생성한다.

각 파드가 순서대로 생성되기 때문에 고정된 이름, 볼륨, 설정 등을 가질 수 있다.

# 스테이트풀셋을 다음 명령어로 생성
kubectl apply -f ~/nfs-pvc-sts.yaml

nfs-pvc-sts.yaml

apiVersion: apps/1
kind: StatefulSet
metadata:
name: nfs-pvc-sts
spec:
replicas: 4
serviceName: sts-svc-domain
selector:
  matchLabels:
    app: nfs-pvc-sts
  template:
    metadata:
      labels:
        app: nfs-pvc-sts
    spec:
      containers:
      - name: audit-trail
        image: sytsnet4admin/audit-trail
        volumeMounts:
        - name: nfs-vol
          mountPath: /audit
      volumes:
      - name: nfs-vol
        persistentVolumeClaim:
          claimName: nfs-pvc

# 파드가 정상적으로 생성 되는지 확인
kubectl get pods -w

expose 명령으로는 스테이트풀셋 을 실행할 수 없다. expose 명령으로 서비스를 생성할수 있는 오브젝트는 디플로이먼트, 파드, 레플리카셋, 레플리케이션 컨트롤러 이다.

# 스테이트풀셋을 노출하기 위한 서비스를 생성, 생성한 로드밸런서 서비스를 확dls.
kubectl apply -f ~/nfs-pvc-sts-svc.yaml
kubectl get services

nfs-pvc-sts-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: nfs-pvc-sts-svc
spec:
  selector:
    app: nfs-pvc-sts
  ports:
    - port: 80
  type: LoadBalancer

[Kubernetes] 쿠버네티스 서비스

2021-10-26T00:00:00+00:00

3.3 쿠버네티스 연결을 담당하는 서비스

쿠버네티스에서는 외부에서 쿠버네티스 클러스터에 접속하는 방법을 서비스라고 한다.

3.3.1 가장 간단하게 연결하는 노드포트

노드포트 서비스를 이용하여 외부에서 쿠버네티스 클러스터의 내부에 쉽게 접근할 수 있다.

노드포트 서비스로 외부에서 접속하기

아래 명령어로 노드포트 서비스를 생성 할수 었다.

kebuctl create -f nodeport.yaml

nodeport.yaml

apiVersion: v1
kind: Service
metadata:
  name: np-svc
spec:
  selector:
    app: np-pods
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30000
  type: NodePort

kubectl get services를 실행해 노드포트 서비스로 생성한 np-svc 서비스 확인
```
kubectl get services
```
워커 노드 IP 확인
```
kubectl get nodes -o wide
```
웹 브라우저에서 확인 된 워커 노드 IP 접속
```
http://192.168.1.101:30000
```

부하 분산 테스트하기

expose로 노드포트 서비스 생성하기

노드포트 서비스는 오브젝트 스펙 파일로만 생성하는것 뿐만 아니라 expose 명령어로도 생성할 수 있다.
디플로이먼트를 np-pods로 지정, 서비스의 이름은 np-svc-v2, 타입은 NodePort로 지정, 마지막으로 서비스가 파드로 보내줄 연결 포트를 80번으로 지정
```
kubectl expose deployment np-pods --type=NodePort --name=np-svc-v2 --port=80
```
서비스 확인
```
kubectl get services
```

3.3.2 사용 목적별로 연결하는 인그레스

인그레스는 고유한 주소를 제공해 사용 목적에 따라 다른 응답을 제공하도록 하고, 트래픽에 대한 L4/L7 로드밸런서와 보안 인증서를 처리하는 기능을 제공한다.
인그레스를 사용하기 위해서는 인그레스 컨트롤러가 필요하다.

인그레스를 위한 설정 파일 예시

ingress-config.yaml

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress-nginx # 이름을 통해서 통신할 ingress 컨트롤러를 확인
  annotations:
  nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules: # 규칙을 지정
  - http:
      paths: 
      - path: #기본 경로 규칙
        backend: # 연결되는 서비스와 포트
          serviceName: hname-svc-default
          servicePort: 80
      - path: /ip
        backend:
          serviceName: ip-svc
          servicePort: 80
      - path: /your-directory
        backend:
          serviceName: your-svc
          servicePort: 80

kubectl get ingress -o yaml 명령어를 통해 인그레스 내용이 확실하게 적용됬는지 확인 가능.

포트 포워딩 기능 예시

ingress.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
spec:
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 30100
  - name: https
    protocol: TCP
    port: 443
    targetPort: 443
    nodePort: 30101
  selector:
    app.kubernetes.io/name: ingress-nginx
  type: NodePort

3.3.3 클라우드에서 쉽게 구성 가능한 로드밸런서

쿠버네티스에서는 로드밸런서라는 서비스 타입을 제공해 파드를 외부에 노출하고 부하를 분산 한다.
클라우드에서 제공하는 쿠버네티스를 사용하고 있다면 다음과 같은 선언으로 사용할 수 있다.
```
kubectl expose deployment ex-lb --type=LoadBalancer --name=ex-svc
```

3.3.4 온프레미스에서 로드밸런서를 제공하는 MetalLB

MetalLB는 베어메탈(운영체제가 설지되지 않은 하드웨어)로 구성된 쿠버네티스에서도 로드밸런서를 사용할 수 있게 고안된 프로젝트이다.
MetalLB는 기존의 L2 네트워크와 L3 네트워크로 로드밸런서를 구현한다.
MetalLB 컨트롤러는 작동 방식을 정의하고, EXTERNAL-IP를 부여해 관리 한다.

MetalLB는 ConfigMap 오브젝트를 사용하는데, 설정 예시는 다음과 같다.

metallb-l2config.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: nginx-ip-range
      protocol: layer2
      addresses:
      - 192.168.1.11-192.168.1.13

configMap 생성여부 및 적용이 잘 됬는지는 아래 명령어로 확인 가능.

kubectl get configmap -n metallb-system # 생성 확인
kubectl get configmap -n metallb-system -o yaml # 적용 확인
kubectl expose deployment lb-hname-pods --type=LoadBalancer --name=lb-hname-svc --port=80 # 각 디플로이먼트를 로드밸런서 서비스로 노출

3.3.5 부하에 따라 자동으로 파드 수를 조절하는 HPA

부하량에 따라 디플로이먼트의 파드 수를 유동적으로 관리하는 기능을 HPA라고 한다.
부하량 확인 (리눅스 top과 비슷)
```
kubectl top pods
```
HPA가 자원을 요청할 떄 메트릭 서버를 통해 계측값을 전달받으므로 메트릭 서버를 설정해야한다.
메트릭서버 또한 서비스와 마찬가지로 오브젝트 스펙파일로 설치 가능하다.

scale 기준 값을 설정하여 파드 증설 시점을 지정 할 수 있다.

edit 명령어로 디플로이먼트 설정 내용 수정

resources:
  requests:
    cpu: "10m" # cpu 0.01 사용을 기준으로 파드를 증설
  limits:
    cpu: "50m" # cpu 0.05로 사용 제한

hpa-hname-pods에 autoscale을 설정

kubectl autoscale deployment hpa-hname-pods --min=1 --max=30 --cpu-percent=50
# min은 최소 파드의 수, max는 최대 파드의 수, cpu-percent는 CPU 사용량이 50% 넘을 떄 autoscale 하겠다는 조건