[MLOps] CKA Mock Exam 틀린거 정리

Deployment에 serviceaccount 추가

pod과 동일하게 spec밑에 serviceaccountName 정보를 넣어줘야한다

spec:
      serviceAccountName: dashboard-sa

Linux 명령어 관련

tr 명령어

tr [arg1] [arg2] : arg1을 arg2로 변환 - 출력에서 스페이스 대신 개행으로 출력이 필요하다면 : tr " " "\n" 으로

 

awk명령어

정확하게는 모르지만, arg1 arg2 arg3 이 있을때 arg2만 출력하고싶다면 awk '{print $2}' 로 활용

kubeconfig 파일 오류확인 방법

kubectl cluster-info --kubeconfig=CKA/super.kubeconfig

kubeadm 으로 certification 만료했는지 확인하는방법 & 갱신방법(simulator문제)

# 만료여부 확인
kubeadm certs check-expiration

# 갱신
kubeadm certs renew apiserver
# 뒤에 apiserver말고 다른것도 사용이 가능하다 renew -h로 확인가능

kubectl run으로 메모리, Cpu정보값 추가 하는법(simulator문제)

--requests라는 명령어를 사용하면된다

kubectl run my-static-pod \
	--image=nginx:1.16-alpine \
    --requests="cpu=10m,memory=20Mi" \
    -o yaml --dry-run=client > my-static-pod.yaml

kubectl yaml 파일 출력할때 명령어 포함시키기(simulator문제)

명령어를 -o yaml 앞에 넣게되면 옳바르게 hi.yaml파일에 pod정보가 안담김

kubectl run hi --image=nginx:alpine --dry-run=client -o yaml -- sleep 1000 > hi.yaml

kubelet 실행 경로 설정(simulator문제)

kubelet이 죽어있어서 start로 활성화를 시켜도 제대로 실행이 안되는 문제였고, 에러문에서는 kubelet실행파일을 못찾는다는 원인이 출력됐다

# 먼저 kubelet실행파일이 어디에 위치로 향해있는지 확인
whereis kubelet

# 우리가 원하는 위치가 아니라면 다음경로 파일수정
vim /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

# systemctl restart kubelet
systemctl daemon-reload && systemctl

# check kubelet status
systemctl status kubelet

특정 namespace의 모든 Api Resources 출력(simulator문제)

kubectl api-resources --namespaced -o name

Cluster Even조회(simulator문제)

모든 클러스터 이벤트 정보를 시간순대로 나열하여 출력

kubectl get events -A --sort-by=.metadata.creationTimestamp

CIDR 조회(simulator문제)

cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep range

node label 추가 관련

# 특정 node에 color=blue라는 label추가
kubectl label node node01 color=blue

nodeAffinity에서 value값이 필요없을경우

즉, show labels를 했을때 value값이 없는 경우(등호만 있고 다른값은 없을때)

nodeAffinity에 operator를 Exists로 설정한다

taint 관련

# 특정 요소로 node taint
kubectl taint node node01 env_type=production:NoSchedule

Pod, Node Resource check

kubectl top nodes
kubectl top pods

ReadnessProbe, livenessProbe

https://bluayer.com/43

[Kubernetes] 4. LivenessProbe, ReplicationController, ReplicaSet, DaemonSet, Job, CronJob

kubectl config 관련

# 아래와 같은 명령어로 도움받을수있고
kubectl config -h

# 현재 context정보는
kubectl config get-contexts

# kubectl 없이 현재 Context정보를 얻으려면 (중요)
cat ~/.kube/config | grep -i "current-context" | awk '{print $2}'

PV, PVC문제

emptyDir

Create a Pod called redis-storage with image: redis:alpine with a Volume of type emptyDir that lasts for the life of the Pod

DNS Lookup

nslookup으로 service와 pod이 조회가 되는지, 그 결과를 파일로 저장하는 문제

여기서 중요한 nslookup에 pod정보를 넣을때 pod의 ip는 .에서 -으로 바꿔줘야하고 뒤에 .default(namespace).pod(resource)를 적어줘야한다.

즉, pod의 ip가 10.50.192.1이라고 할때 nslookup 10-50-192-1.default.pod 라는 명령어를 날려줘야한다.

Create a nginx pod called nginx-resolver using image nginx, expose it internally with a service called nginx-resolver-service. Test that you are able to look up the service and pod names from within the cluster. Use the image: busybox:1.28 for dns lookup. Record results in /root/CKA/nginx.svc and /root/CKA/nginx.pod

# Use the command kubectl run and create a nginx pod and busybox pod.
# Resolve it, nginx service and its pod name from busybox pod.
# To create a pod nginx-resolver and expose it internally:

kubectl run nginx-resolver --image=nginx
kubectl expose pod nginx-resolver --name=nginx-resolver-service --port=80 --target-port=80 --type=ClusterIP

# To create a pod test-nslookup.
# Test that you are able to look up the service and pod names from within the cluster:

kubectl run test-nslookup --image=busybox:1.28 --rm -it \
	--restart=Never -- nslookup nginx-resolver-service

kubectl run test-nslookup --image=busybox:1.28 --rm -it \
	--restart=Never -- nslookup nginx-resolver-service > /root/CKA/nginx.svc

# Get the IP of the nginx-resolver pod and
# replace the dots(.) with hyphon(-) which will be used below.

kubectl get pod nginx-resolver -o wide
kubectl run test-nslookup --image=busybox:1.28 --rm -it \
	--restart=Never -- nslookup <P-O-D-I-P.default.pod> > /root/CKA/nginx.pod

ETCD Backup

ETCD Backup문제는 흔하게 나오는것같다.

아래 명령어중에 cacert, cert, key file들은 "kubectl get pods -n kube-system"을 통해 etcd pod 이름을 확인하고,

"kubectl describe pods -n kube-system [etcd-pod name]" 을 치면 파일정보들을 확인할수있다.

export ETCDCTL_API=3
etcdctl snapshot save --endpoints https://[127.0.0.1]:2379 --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key  /opt/etcd-backup.db

staticPod 위치 알아내는방법 + staticPod의 정확한 의미

service kubelet status 명령어 이후 - Drop-In쪽 파일 경로 확인

- KUBELET_KUBECONFIG_ARGS, KUBELET_CONFIG_ARGS 에 대응하는 파일들 확인

- KUBELET_CONFIG_ARGS위치 파일을 열어보면 밑에 staticPodPath정보를 확인할수있음

 

staticPod이란(https://coffeewhale.com/kubernetes/authentication/x509/2020/05/02/auth01/#:~:text=4.,%ED%95%98%EB%8A%94%20Pod%EB%A5%BC%20%EC%9D%98%EB%AF%B8%ED%95%A9%EB%8B%88%EB%8B%A4.)

쿠버네티스에는 Static Pod라는 개념이 존재합니다. kubelet에서 API 서버의 요청과는 상관 없이 특정 디렉토리 안의 Pod YAML 정의서를 바라보고 직접 생성하는 Pod를 의미합니다. api-server와 무관하게 생성된다는 점 이외에는 일반 Pod와 동작 방식이 동일합니다. kubeadm으로 쿠버네티스 클러스터 구축시, Static Pod의 default 디렉토리로 /etc/kubernetes/manifest를 바라봅니다. 앞으로 여러 인증 체계를 살펴보기 위해서는 api server의 설정값을 직접 고쳐야하는 경우가 많은데 kubeadm에서는 이 api 서버가 바로 Static pod로 만들어지기 때문입니다. (어찌보면 당연한 얘기 같습니다. api 서버를 생성하기 위해서 api 서버에 Pod 생성 요청을 할 수 없으니 Static Pod를 통해서 api 서버를 생성합니다. 이러한 이유 때문에 kubeadm이 아닌 다른 쿠버네티스 설치툴에서는 kube-apiserver와 같은 core 컴포넌트들을 Pod (컨테이너) 형태가 아닌 일반적인 프로세스로 실행하는 방법을 사용하기도 합니다.)

 

특정 Node에 Pod생성방법

기존에 Pod생성하는것과 동일하지만 spec구조체 밑에 "nodeSelector"구조체 추가

여기서 특정 node의 라벨을 넣어줘야하는데. node들의 label정보는 다음 명령어로 알수있음

kubectl get nodes --show-labels

여기서 나오는 label정보값들을 nodeSelector밑에 추가해줘야함

Dry-run

--dry-run=client옵션은, kubectl 로 실행되는 명령어를 실제로는 수행하지않는걸 뜻함. 예를들어서 어떤 특정 pod을 만드려는 yaml파일이 필요하고, 좀더 복잡한 내용을 '덧 붙히고 싶을 때' 사용한다.

kubectl run hi --image=nginx --dry-run=client -o yaml > hi.yaml

Create & Record Deployment

Mock Exam에서 특정 과정에 대해서 record를하라는 문제가 있었는데, 단순하게 --record옵션을 붙히면 되는거였다.

# 실제로는 Deployment를 만들지는 않고, yaml파일만 생성
kubectl create deployment nginx-deploy --image=nginx:1.16 --dry-run=client -o yaml > deploy.yaml

# deployment를 생성됨과 동시에 기록도 시작
kubectl apply -f deploy.yaml --record

# history 확인
kubectl rollout history deployment nginx-deploy

# 업데이트를 하는 과정도 기록
kubectl set image deployment/nginx-deploy nginx=nginx:1.17 --record

# history 확인
kubectl rollout history deployment nginx-deploy

Role & Rolebinding 명령어로 생성

kubectl create role developer --resource=pods --verb=create,list,get,update,delete --namespace=development

kubectl create rolebinding developer-role-binding --role=developer --user=john --namespace=development

## 중요!!!
# Context를 바꾸지않고 특정계정 권한체크
kubectl auth can-i create pods --namespace=development --as=john

특정 노드로 파일 이동

# scp명령어 사용
## Node01 의 /root폴더 아래로 파일 이동
scp [File name] node01:/root/

-o=jsonpath 관련

type이 InternalIP인것만 가져오기

kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}'

NetworkPolicy 관련

kubeadm upgrade

https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/

Upgrading kubeadm clusters

위 문서가 있긴한데... 그래도 잘안될때가 있는것같다. 그리고 다른 워커노드에 대해서도 업그레이드 하는방법을 알아야한다.

(파랑색 부분은 node01위에서 작업해야하는 명령어들이다)

1. 먼저 controlplane에 대해 drain 작업
2. apt-get update -> apt-get install kubeadm=1.20.0-00
3. kubeadm upgrade plan v1.20.0
4. kubeadm upgrade apply v1.20.0
5. apt-get install kubelet=1.20.0-00
6. systemctl daemon-reload
7. systemctl restart kubelet
8. kubectl uncordon controlplane
9. kubectl drain node01 --ignore-daemonsets
10. apt-get update
11. apt-get install kubeadm=1.20.0-00
12. kubeadm upgrade node
13. apt-get install kubelet=1.20.0-00
14. systemctl daemon-reload
15. systemctl restart kubelet
16. kubectl uncordon node01