Rala
repo

Kubernetes cheatsheet

Github logo Edit on GitHub

Kubenetes cheatsheet

쿠버네티스 관련 후딱 참조. 한꼭지가 길어지면 별도 글이 될 수 있다.

특징

선언적(declarative) 인프라. 서버 하나를 띄우라고 했으면 계속 띄우려고 노력한다. 죽었으면 다시 살리면서.

kubeadm

쿠버네티스 클러스터 설정 프로그램?

kubeadm init

쿠버네티스 컨트롤 패널(마스터노드) 초기화

kubadm init
--token [token] # 초기화 토큰. worker  노드들이 join할 때 사용
--apiserver-advertise-address=[api 서버 ip주소]

kubeadm join

워커 노드들이 접속할 때 사용

kubeadm join
--token [token] # 마스터 노드에서 생성한 토큰
--discovery-token-unsafe-skip-ca-verification [api 서버 ip주소]:[6443]  #마스터노드 ip주소를 이용하여 조인. 6443이 마스터노드 api 서버 기본 포트
#worker->master로 가는 6443 포트가 오픈되어 있어야 통신 가능

kubectl

쿠버네티스 컨트롤 cli 프로그램

kubectl get nodes                   # 현재 연결된 노드 확인. 마스터 및 워커
kubectl get pods --all-namespaces   # 전체네임스페이스(default 제외)의 pod 다 보기
kubectl get pods -n [namespacename] # 네임스페이스 이름의 pod 다보기
kubectl get deployment [deploymentname] # 배포 정보
kubectl get ingress                  # 인그레스 땡겨오기
kubectl get ingress -o yaml         # 인그레스 yaml 가져오기
kubectl get pods -n metallb-system -o wide -w   # -w = watch. tail과 흡사. 변경되면 바로 보여줌.
kubectl get pv                      # persistence volume 보기
kubectl get pvc                     # persistence volume claim 보기


kubectl get configmap -n metallb-system # 네임스페이스안의 configmap 확인하기


kubectl get serviceaccounts # serviceaccounts 보기

kubectl 실행

kubectl은 api서버의 접속정보(ip, port, 인증 정보 등)만 있으면 api서버로 명령 가능

설정파일위치

/etc/kubernetes/admin.conf

# kubeconfig를 통해 api 서버 설정 정보를 던질 수 있음. 즉, 다른 서버라도 해당 정보만 있으면 사용 가능.
kubectl get nodes --kubeconfig /etc/kubernetes/admin.conf

kubectl 명령어



# pod 확인
kubectl get pod                         # pod  확인
kubectl get pod -o wide                 # 전체 columns 보기
kubectl get pod -o=custom-culumns=NAME:.metadata.name,IP:.ststus.podIP,STATUS:.ststus.phase,NODE:.spec.nodeName        # 보고싶은 컬럼만 보기
kubectl get hpa                         # 오토스케일러보기. horizontal Pod Autoscaler


# 생성
kubectl run nginx-pod --image=nginx     # pod 실행
kubectl create deployment dpy-nginx --image=nginx   # pod 생성은 배치를 생성하는 것
#==>                      파드명             컨테이너 이미지명


kubectl create deployment dpy-hname --image=sysnet4admin/echo-hname # 배포 생성
kubectl create -f [filename]                                        # yaml 파일을 이용한 생성
kubectl create deployment failure2 --dry-run=client -o yaml --image=multiple-img > failure2.yaml # 배포를 yaml로 생성.


kubectl create clusterrolebinding jenkins-cluster-admin --clusterrole=cluster-admin --serviceaccount=default:jenkins
# 클러스터 롤 바인딩 생성. jenkins-cluster-admin이라는 이름으로 생성하며, cluster-admin 롤을 부여. 생성된 롤을 서비스 어카운트[default:jenkins]에 부여.




kubectl apply -f [filename]                                         # 변경사항 반영하여 다시 프로비저닝. 예를 들어 replicaset의 수를 바꿀 때, create를 하면 동일 pod이 있으므로 생성되지 않지만, apply를 하면 변경사항이 잘 반영됨. 물논, 처음부터 apply로 생성이 가능하다.


kubectl delete deployment dpy-hname                                 # 배포 삭제
kubectl delete pod --all -n metallb-system                          # 네임스페이스 네의 전체 pod 삭제
kubectl delete resourcequotas storagequota                          # 리소스에 대한 제약을 삭제(PV, PVC 용량 등)


# 스케일링
kubectl scale deployment dpy-home --replicas=3                      # 배포의 pod 레플리카를 3개로 만듦


kubectl exec -it nginx -- ls -al /tmp                               # 실행중인 pod에서 명령 실행. "--" 뒤로 명령어를 붙여 넣어 줌.


# 스케줄링 일시중지
kubectl cordon w3-k9s                                               # 저지선. node 스케줄링 금지
kubectl uncordon w3-k9s                                             # 저지선 해제. node 스케줄링 금지 금지.


# 작업 기록
kubectl apply deployment -f [filename] --record                    # --record. 생성, 변경 등 기록
kubectl rollout status deployment rollout-nginx                            # 롤아웃 작업에 대한 현재 상태 확인
kubectl rollout history deployment rollout-nginx    # 기록된 rollout 정보 가져오기
kubectl set image deployment rollout-nginx nginx=nginx-1.17.23  # deployment의 이미지를 변경
kubectl rollout undo deployment rollout-nginx       # rollout 작업 취소. ex) 이미지 변경 취소
#describe(kubectl describe deployment rollout-nginx)를 땡겨보면 kubectl set image deployment rolloug-nginx nginx=nginx.1.16.0 --record=true를 수행하였으며 revision은 4로 올라가 있음. 즉, 이전으로 revision(2)으로 돌아가는 것이 아니라 history에서 바로 이전 리비전의 명령을 수행함.
kubectl rollout undo deployment rollout-nginx  --to-revision=1  # 특정 리비전으로 undo. 입력한 리비전의 명령을 히스토리에서 실행시키며 현재 리비전은 +1


#서비스 공개
kubectl expose deployment np-pods --type=NodePort --name=np-svc-v2 --port=80    # 외부 포트 공개. deployment(np-pods)의 80으로 트래픽을 던지는 np-svc-v2라는 NodePort 서비스를 생성


kubectl expose deployment lb-hname-pods --type=LoadBalancer --name=lb-hname-svc --port=80 # 로드밸런서 : metallb를 이용






# 상태 확인
kubectl describe deployment rollout-nginx                           # 배포 상태 확인.


kubectl top pods    # linux의 top과 같음


# 오토스케일링
kubectl autoscale deployment hpa-hname-pods --min=1 --max=30 --cpu-percent=50

커스터마이즈(kustomize)

오브젝트, 리소스 등의 설정 파일을 야믈로 관리. yaml로 자우너을 선언하고 자원을 배포할 수 있는 모든 자원이 선언된 최종 yaml을 생성하는 것이 목표.



kustomize create --namepsace=metallb-system --resources namespace.yaml,metallb.yaml,metallb-l2config.yaml
# kustomization.yaml 파일 생성. metallb-system이라는 네임스페이스로 생성하며, namespace.yaml, metallb.yaml, metallb-l2config.yaml을 리소스로 땡김


kustomize edit set image metallb/controller:v0.8.2
# kustomization.yaml파일을 수정하여 이미지 정보 삽입


kustomize build # kutomization.yaml을 이용하여 배포 정보가 담긴 yaml 생성
kustomize build | kubectl apply -f -  # 생성된 배포 파일(yaml)을 파이프로 던져서 컨테이너 생성

헬름(helm)

패키지 매니저. 패키지 검색, 관리, 의존성 관리, 보안 관리 등 가능. 헬름>커스터마이즈>큐베시티엘(쿠베컨트롤?)

차트

쿠버네티스 패키지



#설치 for Linux
$ curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 > get_helm.sh
$ chmod 700 get_helm.sh
$ ./get_helm.sh


# 저장소 추가. edu라는 이름으로 저장소 주소를 추가한다.
helm repo add edu https://iac-source.github.io/helm-charts
helm repo update  # 저장소 추가


helm install metallb edu/metallb \  # metallb라는 컨테이너를 edu/metallb 저장소의 컨테이너로부터 가져옴
--namespace=metallb-system \  # 컨테이너 네임스페이스는 metallb-system
--create-namespace \  # 네임스페이스가 없으면 생성하고,
--set controller.tag=v0.8.3 \ # 내부에서 사용할 기타 환경변수를 설정
--set speaker.tag=v0.8.3 \
--set configmap.ipRange=192.168.1.11-192.168.1.29

pod 네이밍 규칙

pod 네이밍 규칙은 다음과 같다.

name-hash

[name****]-[hash] kube-proxy-479b7 kube-proxy-hdgfn

name-replicaset-hash

[name*]-[replica*]-[hash] coredns-5644d6b6d9-b4dz9 coredns-5644d6b6d9-jmsxh

오브젝트

pod, service, volume, namespace

오브젝트 스펙

yaml파일로 작성된 오브젝트의 스펙

NodePort

서비스를 위하여 pod로 갈 포트 노출

Ingress

서비스를 위하여 pod로 갈 포트 노출.

인그레스 설정

1. 서비스할 배포 적용
kubectl apply -f deployment.yaml


2. 인그래스(패스, 포트 등 연결 설정) 설치
kubectl apply -f ingress-install.yaml
kubectl apply -f ingree-config.yaml


3. 노드포트 설정하여 서비스(노드포트)포트로부터 pod의 포트까지 연결
kubectl apply -f nodeport.yaml


4. 배포를 서비스할 수 있는 서비스 생성: deployment에 clusterip:port에 해당하는 서비스를 생성
kubectl expose deployment [deploymentname]  --name=[servicename] --port=80,443

데몬셋

싱글 pod에서 수행.

컨피그맵

일반적인 설정 저장

볼륨

  • 임시 : emptyDir
  • 로컬 : host Path, local
  • 원격 : persistentVolumeClaim, cephfs, cinder, csi, fc, flexVolume, flocker, glusterfs, iscsi, nfs, vsphereVolume
  • 특수 목적 : downwardAPI, configMap, secret, azureFile, proejcted
  • 클라우드 : awsElasticBlockStore, azureDisk, gcePersistentDisk

PV(PersistentVolume)과 PVC(PersistentVolumeClaim)

영구 볼륨 요청? 영구 볼륨 요청? 예를들어,

  • PV : 1TB 하드 디스크
  • PVC : 컨테이너에스 사용할 100GB 요청

스테이트풀셋

개별 pod의 구분이 가능한 deployment. pod의 상태를 확인할 필요가 있때(EX. DB를 master/slave로 구성할 때 등) 사용 expose를 지원하지 않으므로 별도 서비스를 생성하여야 함.

테인트와 톨러레이션

taints and tolerations

  • 테인트 : 노드가 중요한 부분. 마스터 노드같은. 아래 정보로 구성
    • key : 필수
    • value : 옵션
    • effect : 테인트와 톨러레이션이 맞지 않을 때 동작
      • noschedule : 신규 - 노드에 파드 배치 거부. 배치된 경우 - 노드에 배치된 파드만 유지
      • prefernoschedule : 신규 - 다른 노드에 파드 배치가 불가능할 때는 노드에 파드 배치, 배치된 경우 - 노드에 배치된 파드만 유지
      • noexecute : 신규 - 노드에 파드 배치 거부. 배치된 경우 - 파드에서 노드 제거
  • 톨러레이션 : 테인트에 배치해야할 중요한 파드. 테인트 정보를 적음.(=> ex. 중요한 컨테이너이므로 마스터 노드에 배치)
    • 구성 : key, value, effect, operator
    • 테인트에 파드를 배치하려면, 파드의 톨러레이션의 키와 이펙트가 테인트의 키, 이펙트와 동일하여야 함.
    • key : opt. null이라면 모든 key
    • effect : opt. null이라면 모든 효과
    • operator :
      • default=equal. 테인트와 톨로레이션의 조건(key, value, effect)이 맞으면 배치.
      • exists : 키와 효과의 일치 판단. 값은 반드시 생략.

참고

  1. Kubeadm으로 K8S 구성 : https://velog.io/@seunghyeon/Kubeadm%EC%9C%BC%EB%A1%9C-K8S-%EA%B5%AC%EC%84%B1
Previous
Active Directory를 이용한 Kubenetes 인증
Next
Linux cheatsheet