[CKAD] killer.sh 틀린 문제 풀이

유의 사항 

k8s에서 개수확인 문제에흔 --no-header를 넣어야 한다. 안그럼 header가 폼되면서 개수 틀려짐.

Pod-ENV

env로 key value 설정하기 

env:
  - name: TEST
    value: HAHAHAH

resource에서 직접 key 값 가져오기 

env:
  - name: DB_PASSWORD
    secretKeyRef:
      name: db-secret
      key: password
  - name: APP_CONFIG
    configMapKeyRef:
      name: app-config
      key: config.json
  - name: POD_NAME
    fieldRef:
      fieldPath: metadata.name
  - name: CPU_LIMIT
    resourceFieldRef:
      containerName: my-container
      resource: limits.cpu

valueFrom으로 resource의 key 값 가져오기 

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password
  - name: APP_CONFIG
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: config.json
  - name: POD_NAME
    valueFrom:
      fieldRef:
        fieldPath: metadata.name
  - name: CPU_LIMIT
    valueFrom:
      resourceFieldRef:
        containerName: my-container
        resource: limits.cpu

evnFrom으로 configmap과 secret 전체 가져오기

envFrom:
  - configMapRef:
      name: myconfig
  - secretRef:
      name: mysecret

5. volume을 통해서 가져오기

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: nginx
      volumeMounts:
        - name: config-volume
          mountPath: /etc/config
        - name: secret-volume
          mountPath: /etc/secret
  volumes:
    - name: config-volume
      configMap:
        name: myconfig
    - name: secret-volume
      secret:
        secretName: mysecret

6. volume에서 특정 키의 값만 mount하는 방법

volumes:
  - name: myconfig
    configMap:
      name: myconfig
      times:
        - key: log_level
          path: log-level.txt
  - name: secret
    secret:
      secretname: mysecret
      times:
        - key: secret_level
          path: secret_level.log

 

사용법 쉽게 외우기 

env 는 key를 사용하여 가져옴으로 configMapKeyRef  및 secretKeyRef 가 사용된다. 

- properties 로 name과 key가 존재

envFrom은 전체를 가져옴으로 configMapRef 및 secretRef 가 사용된다. 

- properies로 name가 존재 

volume은 전체를 가져옴으로 configMap 및 secret이 사용된다.

- properties로 name 및 secretName이 존재

Pod 상태 확인

status로 상태를 확인

kubectl -n default get pod pod1 | grep -i status:

kubectl -n default get pod pod1 -o jsonpath="{.status.phase}"

heml  chart 관련 명령어

설치 

helm install -n test {release_name} {char_name}

repo 관련 명런

보기

helm repo list

업데이트

helm repo update

chart 검색

helm search repo nginx

설치되 chart update하기 

helm --n test upgrade {releae_name} {chart_name}

chart 설치시 replicaCount 설정

helm -n test install {release_name} {char_name} --set replicaCount=2

현재 설치된 모든 release나열 

helm ls

release 삭제

Service Account에 할당된 token 찾는 방법

secret의 annoation에 sa 정보가 존재한다. 그걸 찾은다음에 secret의 내용을 보면된다. 

k -n neptune get sa # get overview
k -n neptune get secrets # shows all secrets of namespace
k -n neptune get secrets -oyaml | grep annotations -A 1 # shows secrets with first annotation
k -n neptune describe secret neptune-secret-1 #token 확인

Pod에서 command  사용시 주의 사항

sh -c 를 꼭 넣어주어야 한다. 이유

• 쉘 연산자(&&, |, ||, ;) 사용: 논리적 연결이 필요할 때 쉘이 있어야 합니다.
• 명령어 문자열 해석: 여러 명령어를 하나의 문자열로 해석하기 위해 필요합니다.
• 복잡한 커맨드 실행: 단순한 명령어 외에 파이프라인(|)이나 조건문(&&, ||)이 포함된 명령어는 쉘이 있어야 제대로 작동합니다.

주의사항

• Kubernetes는 command 필드에서 각 인자를 개별적으로 해석합니다. 그래서 공백이 포함된 인자는 하나의 문자열로 취급되기 위해 감싸는 것이 더 안전할 수 있습니다.
• 쉘(sh -c)을 사용하는 경우, 공백과 연산자(&&, ||)가 포함된 명령어는 감싸는 것이 권장됩니다.

 

spec:
  containers:
  - command:
    - sh
    - -c
    - "touch /tmp/ready && sleep 1d"

 

securityContext 위치 

Pod와 container 두개다 위치 가능 

  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000

contaner에서 설정 사항 

        securityContext:                   # add
          allowPrivilegeEscalation: false  # add
          privileged: false                # add

k8s에서 Sidecar란?

K8s의 사이드카 컨테이너는 restartPolicy: Always가 있는 initContainers입니다.

이전에는 사이드카 컨테이너를 일반 컨테이너로 정의해야 했지만, Kubernetes 1.28부터는 initContainers에 restartPolicy: Always를 설정하여 사이드카 컨테이너를 명시적으로 정의할 수 있게 되었습니다.

k8s  임시 container 만들기 

kubectl run tmp --rm -i --image nginx:alpine --restart=Never -- curl 10.10.0.10

 

• --rm 옵션은 Pod가 종료된 후 자동으로 삭제되도록 합니다.
• -i 옵션이 없으면, Pod는 입력이 연결되지 않은 상태로 시작되기 때문에, curl 명령이 제대로 실행되지 않거나 바로 종료될 수 있습니다.
• 특히 kubectl run 명령에서 -i 없이 실행할 경우, 명령이 백그라운드에서 실행되고 표준 입력이 닫혀서 예상대로 동작하지 않을 수 있습니다.

sts scale 조정하기 

대상 : deployment, replicaset, statefullset 

kubectl -n test scale sts 03db -replicas 1

k8s node resource 확인

node만 확인

kubectl top nodes

container들을 확인

kubectl top pod --containers=true

Pod scheduling 하기 

1. scheduller 멈추기

static schedule yaml을 옮기면된다. 

cd /etc/kubernetes/manifests/
mv kube-scheduler.yaml ..

2. pod 생성

k run manual-schedule --image=httpd:2.4-alpine

 

3. pod에 nodeName 설정

이렇게 되면 schedulle 없이도 node에 배치가 된다.

  nodeName: cluster2-controlplane1        # add the controlplane node name

 

이게 가능한 이유

1. Pod 생성

• 사용자가 Pod 생성 요청을 하면, API Server가 이 요청을 받아서 etcd에 저장합니다.
• 이 시점에서 Pod의 상태는 Pending이고, NodeName 필드는 비어 있습니다.

2. Scheduler의 동작

• Scheduler는 주기적으로 API Server에서 Pending 상태의 Pod 목록을 가져옵니다.
• Scheduler는 스케줄링 알고리즘을 사용하여 적합한 Node를 선택하고, 이 Node의 이름을 Pod의 NodeName 필드에 설정합니다.
• Scheduler는 업데이트된 Pod 정보를 API Server에 다시 전송하고, API Server는 이를 etcd에 저장합니다.

3. Kubelet의 동작

• Kubelet은 주기적으로 API Server에 자신이 관리하는 Node에 할당된 Pod의 목록을 요청합니다.
• 자신에게 할당된 Pod가 있으면, Kubelet은 Pod의 스펙을 가져와서 컨테이너 런타임을 통해 해당 Pod의 컨테이너를 실행합니다.
• Kubelet은 Pod의 상태를 지속적으로 모니터링하고, 이 정보를 API Server에 보고합니다.

Role

• 같은 apiGroup에 속하는 경우라면 하나의 rule에 여러 resources를 포함할 수 있습니다.
• 다른 apiGroup에 속하거나, 권한을 세분화하려면 rule을 추가로 정의하는 것이 좋습니다.

rules:
  # Core API group (빈 문자열)
- apiGroups:
    - ""
  resources:
    - configmaps
  verbs:
    - get
    - list

  # Custom API group
- apiGroups:
    - "apps"
  resources:
    - deployments
  verbs:
    - update

cluster 정보 수집

1. How many controlplane nodes are available?

k get node 로 확인

2. How many worker nodes are available?

k get node 로 확인

3. What is the Service CIDR? 

CIDR 표기법 : <IP 주소>/<서브넷 마스크의 길이>

답 : 10.96.0.0/12

root@cluster1-controlplane1:~# cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep range

    - --service-cluster-ip-range=10.96.0.0/12

4. Which Networking (or CNI Plugin) is configured and where is its config file?

답 : weave, /etc/cni/net.d/10-weave.conflist

find /etc/cni/net.d/

10-weave.conflist
cat /etc/cni/net.d/10-weave.conflist
{
    "cniVersion": "0.3.0",
    "name": "weave",
...

 

 

5. Which suffix will static pods have that run on cluster1-node1?

실행 중인 Pod 목록을 조회 (kubectl get pods -A)하여 Mirror Pod의 이름을 확인합니다.

Mirror Pod의 이름 형식에서 Node 이름이 Suffix로 붙는 것을 확인할 수 있습니다 (<Static Pod Name>-<Node Name>).

 

Event 확인

모든 namespace event 확인

kubectl get events -A

api-resources 확인

namespaced resource확인

kubectl api-resources --namespaced 

kubectl api-resources --namespaced -o name 

kubelet이 안된다. 

1. kubelet이 실행중인지 확인. 

2. kubelet 실행 파일 경로가 정상인지 확인 

k8s worker node join 

특정 버전으로 kubelet 업데이트하기 

apt update

apt show kubelet | grep 1.31

apt install -y kubelet=1.13.1-1.1 kubectl=1.13.1-1.1

service restart kubelet

command 만들기 

kubeadm token create --print-join-command

openssl로 인증서 날짜 확인하기 

openssl x509 -in 인증서 -noout -text

에서 Validity 확인

 

kubeadm certs check-expiration | grep apiserver

kube-apiserver 인증서를 갱신

sudo kubeadm certs renew apiserver

NetworkPolicy 규칙

"-" 를 한개의 Rule로 봅니다.

• "-" 를 개별 Rule로 인식하여 or 조건으로 동작
• "-" 안의 Rule들은 And 조건으로 동작 

예를 들어 아래 설정에서 ipblock, namespaceSelector, podSelector는 각각 개별 룰로 취급되며 or 조건으로 동작합니다.

  ingress:
    - from:
        - ipBlock:
            cidr: 172.17.0.0/16
            except:
              - 172.17.1.0/24
        - namespaceSelector:
            matchLabels:
              project: myproject
        - podSelector:
            matchLabels:
              role: frontend

 

그러나 아래 설정에서는 ipblock과  namespaceSelector는 and로 동작하고 podSelector는 개별 룰로 취급 or 조건으로 동작합니다.

 

  ingress:
    - from:
        - ipBlock:
            cidr: 172.17.0.0/16
            except:
              - 172.17.1.0/24
          namespaceSelector:
            matchLabels:
              project: myproject
        - podSelector:
            matchLabels:
              role: frontend