meatsby.github.io

09. CKA

Properties1
tagsk8s

41 min read

CKA

25년 2월 18일 변경 이후 시험 범위

  • Cluster Architecture, Installation & Configuration 25%
    • Manage role based access control (RBAC)
    • Prepare underlying infrastructure for installing a Kubernetes cluster
    • Create and manage Kubernetes clusters using kubeadm
    • Manage the lifecycle of Kubernetes clusters
    • Implement and configure a highly-available control plane
    • Use Helm and Kustomize to install cluster components
    • Understand extension interfaces (CNI, CSI, CRI, etc.)
    • Understand CRDs, install and configure operators
  • Workloads & Scheduling 15%
    • Understand application deployments and how to perform rolling update and rollbacks
    • Use ConfigMaps and Secrets to configure applications
    • Configure workload autoscaling
    • Understand the primitives used to create robust, self-healing, application deployments
    • Configure Pod admission and scheduling (limits, node affinity, etc.)
  • Services & Networking 20%
    • Understand connectivity between Pods
    • Define and enforce Network Policies
    • Use ClusterIP, NodePort, LoadBalancer service types and endpoints
    • Use the Gateway API to manage Ingress traffic
    • Know how to use Ingress controllers and Ingress resources
    • Understand and use `CoreDNS
  • Storage 10%
    • Implement storage classes and dynamic volume provisioning
    • Configure volume types, access modes and reclaim policies
    • Manage persistent volumes and persistent volume claims
  • Troubleshooting 30%
    • Troubleshoot clusters and nodes
    • Troubleshoot cluster components
    • Monitor cluster and application resource usage
    • Manage and evaluate container output streams
    • Troubleshoot services and networking`

Cluster Architecture, Installation & Configuration 25%

CRI

  • dpkg -i 명령으로 .deb 파일 설치 후 systemctl

JayDemy CRI Question

Prepare a Linux system for Kubernetes. Docker is already installed, but you need to configure it for kubeadm. Task Complete these tasks to prepare the system for Kubernetes:

  • Set up cri-dockerd:
    • Install the Debian package ~/cri-dockerd_0.3.9.3-0.ubuntu-focal_amd64.deb
    • Debian packages are installed using dpkg
    • Enable and start the cri-docker service
  • Configure these system parameters:
    • Set net.bridge.bridge-nf-call-iptables = 1
    • Set net.ipv6.conf.all.forwarding = 1
    • Set net.ipv4.ip_forward = 1
    • Set net.netfilter.nf_conntrack_max = 131072
sudo dpkg -i cri-dockerd_0.3.9.3-0.ubuntu-focal_amd64.deb
sudo systemctl enable --now cri-docker.service
sudo systemctl status cri-docker.service
sudo bash -c 'cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.ip_forward = 1
net.netfilter.nf_conntrack_max = 131072
EOF'
 
sudo sysctl --system  # 적용
 
sysctl net.bridge.bridge-nf-call-iptables  # 검증

kubelet

  • 리눅스 kubelet 로그 보기 journal -u kubulet -r - kubelet의 설정 파일 위치  /var/lib/kublet/config.yaml
  • whereis kubelet  명령어  kubelet 의 바이너리 경로를 확인가능
  • systemctl cat kubelet 쿠블렛 설정파일 위치 찾기

kernel parameter 설정

  • CRI 설치 후 net.ipv4.ip_forward = 1 등 네트워크 설정 (sysctl -p /etc/sysctl.d/k8s.conf)
  • CNI 바로 설정하는 명령어 sudo sysctl -w net.bridge.bridge-nf-call-iptables=1

Cluster Networking

CNI

Prepium CNI Question

Install and configure one Container Network Interface (CNI) plugin from the options below. Available options

  • Flannel v0.26.1 - manifest kube-flannel.yml
  • Calico v3.28.2 - install the Tigera operator manifest, then apply the Calico custom resources manifest tigera-operator.yaml custom-resources.yaml Requirements The CNI you install must:
  • allow pods to communicate with each other
  • support Kubernetes NetworkPolicy enforcement
  • be installed from manifests
# NetworkPolicy 적용이 가능한 Calico 설치
k apply -f operator.yaml
k -n kube-system get configmap kubeadm-config -o yaml | awk '/podSubnet:/{print $2}'  # 10.244.0.0/16
curl -O https://.../custom-resources.yaml > custom-resources.yaml
vi custom-resources.yaml # spec.calicoNetwork.ipPools[0].cidr 변경
k apply -f custom-resources.yaml

kubeconfig

Lighting Lab kubeconfig Question

A kubeconfig file called admin.kubeconfig has been created in /root/CKA. There is something wrong with the configuration. Troubleshoot and fix it.

# vi /root/CKA/admin.kubeconfig
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: XXX...
    server: https://controlplane:6443  # 포트 수정
  name: kubernetes
...
k get nodes --kubeconfig /root/CKA/admin.kubeconfig  # kubeconfig 작동 확인

kubeadm Cluster Upgrade

Lighting Lab Cluster Upgrade Question

Upgrade the current version of kubernetes from 1.34.0 to 1.35.0 exactly using the kubeadm utility. Make sure that the upgrade is carried out one node at a time starting with the controlplane node. To minimize downtime, the deployment gold-nginx should be rescheduled on an alternate node before upgrading each node. Upgrade controlplane node first and drain node node01 before upgrading it. Pods for gold-nginx should run on the controlplane node subsequently.

# controlplane
echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.35/deb/ /" > /etc/apt/sources.list.d/kubernetes.list
sudo apt update
sudo apt-cache madison kubeadm
sudo apt-mark unhold kubeadm && \
sudo apt-get update && sudo apt-get install -y kubeadm='1.35.0-1.1' && \
sudo apt-mark hold kubeadm
sudo kubeadm upgrade plan v1.35.0
sudo kubeadm upgrade apply v1.35.0
 
kubectl drain controlplane --ignore-daemonsets
sudo apt-mark unhold kubelet kubectl && \
sudo apt-get update && sudo apt-get install -y kubelet='1.35.0-1.1' kubectl='1.35.0-1.1' && \
sudo apt-mark hold kubelet kubectl
sudo systemctl daemon-reload
sudo systemctl restart kubelet
kubectl uncordon controlplane
# workernode
echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.35/deb/ /" > /etc/apt/sources.list.d/kubernetes.list
sudo apt update
sudo apt-cache madison kubeadm
sudo apt-mark unhold kubeadm && \
sudo apt-get update && sudo apt-get install -y kubeadm='1.35.0-1.1' && \
sudo apt-mark hold kubeadm
sudo kubeadm upgrade node
 
kubectl drain node01 --ignore-daemonsets
sudo apt-mark unhold kubelet kubectl && \
sudo apt-get update && sudo apt-get install -y kubelet='1.35.0-1.1' kubectl='1.35.0-1.1' && \
sudo apt-mark hold kubelet kubectl
sudo systemctl daemon-reload
sudo systemctl restart kubelet
kubectl uncordon node01

ETCD snapshot save & restore

Lighting Lab ETCD Question

Take the backup of ETCD at the location /opt/etcd-backup.db on the controlplane node.

cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep etcd
ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/apiserver-etcd-client.crt \
  --key=/etc/kubernetes/pki/apiserver-etcd-client.key \
  snapshot save /opt/etcd-backup.db
ETCDCTL_API=3 etcdctl --write-out=table snapshot status /opt/etcd-backup.db

RBAC

  • ServiceAccount 생성
  • ClusterRole/Role 생성
  • ClusterRoleBinding 생성 후 확인

CRD

Prepium CRD Question

Task

  1. Create a list of all cert-manager CRDs and save it to /root/resources.yaml
  2. Using kubectl, extract the documentation for the subject specification field on the Certificate Custom Resource and save it to /root/documentation.txt You may use any output format that kubectl supports.
k get crd | grep cert-manager.io > /root/resources.yaml
k explain certificate.spec.subject > /root/documentation.txt

Helm

  • helm 으로 argocd 설치
  • helm install
  • helm upgrade
  • helm get values

JayDemy Helm Question

Install Argo CD in cluster: Add the official Argo CD Helm repository with the name argo. The Argo CD CRDs have already been pre-installed in the cluster. Generate a helm template of the Argo CD Helm chart version 7.7.3 for the argocd namespace and save to /argo-helm.yaml. Configure the chart to not install CRDs. Install Argo CD using Helm with release name argocd using the same version as above and configuration as used in the template 7.7.3. Instaill it in the argocd namespace and configure it to not install CRDs. You do not need to configure access to the Argo CD server UI.

helm repo add argo https://argoproj.github.io/argo-helm
helm repo update
k create ns argocd
helm template argocd argo/argo-cd --namespace argocd --version 7.7.3 --set crds.install=false > /argo-helm.yaml
helm install argocd argo/argo-cd --namespace argocd --version 7.7.3 --set crds.install=false

Workloads & Scheduling 15%

Static Pod

  • /etc/kubernetes/manifests/: static pod

ConfigMap, Secrets

Prepium TLS ConfigMap Question

The secure-web Deployment in namespace secure-space uses a ConfigMap tls-config that currently supports both TLS 1.2 and TLS 1.3. Task: Modify the configuration so that only TLS 1.3 is supported. Note: ConfigMaps are immutable - you must delete and recreate it, then restart the Deployment.

k -n secure-space get cm tls-config -o yaml > tls-config.yaml
vi tls-config.yaml  # TLSv1.2 제거
k -n secure-space delete cm tls-config
k apply -f tls-config.yaml
k -n secure-space rollout restart deployment secure-web  # ConfigMap 적용
k -n secure-space get svc  # ClusterIP 확인
echo '${cluster-ip} ${domain-name}' >> /etc/hosts  # DNS 등록
curl -vk --tls-max 1.2 https://${domain-name}  # 실패해야 정상

Lighting Lab Secret Question

Create a pod called secret-1401 in the admin1401 namespace using the busybox image. The container within the pod should be called secret-admin and should sleep for 4800 seconds.
The container should mount a read-only secret volume called secret-volume at the path /etc/secret-volume. The secret being mounted has already been created for you and is called dotfile-secret.

k config set-context --current -n admin1401
k run secret-1401 --image busybox --dry-run=client -o yaml > pod.yaml
# vi pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: secret-1401
spec:
  containers:
  - image: busybox
    name: secret-admin
    command:
    - 'sh'
    - '-c'
    - 'sleep 4800'
    volumeMounts:
    - name: secret-volume
      readOnly: true
      mountPath: "/etc/secret-volume"
  volumes:
    - name: secret-volume
      secret:
        secretName: dotfile-secret
k apply -f pod.yaml
  • ConfigMap 설정을 이용하는 Pod 가 있을때 ConfigMap 정보를 변경하면 Pod 도 재시작 시켜줘야한다.

Deployment

Lighting Lab Deployment Question

Create a new deployment called nginx-deploy, with image nginx:1.16 and 1 replica.
Next, upgrade the deployment to version 1.17 using rolling update and add the annotation message
Updated nginx image to 1.17.

k create deployment nginx-deploy --image=nginx:1.16 --replicas=1
k set image deployment nginx-deploy nginx=nginx:1.17
  • Deployment 생성 후 이미지 업그레이드
  • Deployment replica 수 수정
  • 파드 환경변수 주입 name/value, secret/configmap, 파드 자체의 정보를 환경 변수로 주입

Sidecar Container

  • 로그 수집 목적 사이드카 컨테이너 추가

Prepium Sidecar Container Question

Update the existing wordpress Deployment in the wordpress-ns namespace, adding a sidecar container named sidecar using the busybox:stable image to the existing pod. The new sidecar container has to run the following command:

/bin/sh -c tail -f /var/log/wordpress.log

Use a volume mounted at /var/log to make the log file wordpress.log available to the co-located container.

# k edit deployment -n wordpress-ns wordpress
...
    volumeMounts:
    - name: logs
      mountPath: /var/log
  - name: sidecar
    image: busybox:stable
    command:
    - "/bin/sh"
    - "-c"
    - "tail -f /var/log/wordpress.log"
    volumeMounts:
    - name: logs
      mountPath: /var/log
  volumes:
  - name: logs
    emptyDir: {}
...

Taint & Toleration, Node Affinity, Node Selector

  • Pod 에 nodeSelector (disktype=ssd) 추가하여 특정 Node 에 배포

Prepium Taints and Tolerations Question

A worker node has been tainted with dedicated=gpu:NoSchedule and labeled gpu=true. A Deployment called web-app already exists in namespace cka-taints. It should not run on the tainted node. Task: Create a pod named gpu-pod in namespace cka-taints that:

  • Uses image nginx:1.25
  • Has a toleration for the taint dedicated=gpu:NoSchedule
  • Has a nodeSelector that targets nodes with label gpu=true
  • Is in a Running state
# vi pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod
  namespace: cka-taints
  labels:
    run: gpu-pod
spec:
  nodeSelector:
    gpu: "true"
  tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"
  containers:
  - image: nginx:1.25
    name: gpu-pod
k apply -f pod.yaml

Resource Requests and Limits

Prepium Resource Requests and Limits Question

The web-app Deployment in namespace resources-ns has 3 replicas but none of the pods are running. A ResourceQuota has been applied to the namespace that limits total CPU and memory. The Deployment does not have resource requests or limits configured, so the pods are being blocked by the quota. Task:

  1. Investigate why the pods are not being created
  2. Inspect the ResourceQuota to find the total CPU and memory budget
  3. Edit the Deployment so that each pod gets an equal share of the quota (requests must equal limits)
  4. Confirm all 3 pods are Running
# k -n resources-ns edit deployment web-app
...
template:
  ...
  spec:
    containers:
	  ...
      resources:
        requests:
          cpu: "10m"
          memory: "10Mi"
        limits:
          cpu: "10m"
          memory: "10Mi"
	  ...

PriorityClass

  • PriorityClass 만들어서 Pod 에 연결

Prepium PriorityClass Question

A Deployment named busybox-logger exists in the priority namespace. An existing user-defined PriorityClass user-existing has value 10000. Task:

  1. Create a new PriorityClass named high-priority with a value one less than the highest existing user-defined value (i.e. 9999)
  2. Patch the busybox-logger Deployment to use high-priority
k create priorityclass high-priority --value=9999
# k -n priority edit deployment busybox-logger
...
template:
  ...
  spec:
	...
    priorityClassName: high-priority
	...

HPA, VPA

  • 존재하는 deployment 에 알맞은 hpa 생성
  • CPU max/min 설정, Stabilization window 구현
  • 보통 docs 복붙 후 필드 수정으로 간단함

JayDemy HPA Question

Create a new HorizontalPodAutoscaler (HPA) named apache-server in the autoscale namespace. This HPA must target the existing Deployment called apache-server in the autoscale namespace.

  • Set the HPA to target for 50% CPU usage per Pod.
  • Configure HPA to have at min 1 Pod and no more than 4 Pods.
  • Also, we have to set the downscale stabilization window to 30 seconds.
k autoscale deployment apache-server --cpu-percent=50 --min=1 --max=4 -n autoscale --dry-run=client -o yaml > hpa.yaml
# vi hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: apache-server
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: apache-server
  minReplicas: 1
  maxReplicas: 4
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  behavior:
    scaleDown:
      downscaleStabilizationWindow: 30
k apply -f hpa.yaml

Services & Networking 20%

CoreDNS

  • /etc/hosts 에서 주소를 찾고 없으면 /etc/resolv.conf 에서 주소를 찾음

Service

  • 이미 배포된 Deployment 의 ContainerPort 를 NodePort 로 expose
  • Pod (port 80) 생성 후 NodePort 타입의 Service 생성

JayDemy Service Question

Reconfigure the existing Deployment front-end in namespace sp-culator to expose port 80/tcp of the existing container nginx. Create a new Service named front-end-svc exposing the container port 80/tcp. Configure the new Service to also expose the individual pods via & NodePort

k expose deployment front-end --type=NodePort --port=80 --protocol=TCP --name=front-end-svc

DumbITGuy Service Question

There is a Deployment named nodeport-deployment in the relative namespace. Tasks:

  • Configure the Deployment so it can be exposed on port 80, name=http, protocol TCP
  • Create a new Service named nodeport-service exposing the container port 80, protocol TCP, NodePort 30080
  • Configure the new Service to also expose the individual pods using NodePort
# k -n relative edit deploy nodeport-deployment
...
template:
  ...
  spec:
    containers:
    - image: nginx
      ...
      ports:
      - name: http
        containerPort: 80
        protocol: TCP
      ...
# vi nodeport-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nodeport-service
  namespace: relative
spec:
  type: NodePort
  selector:
    app: nodeport-deployment
  ports:
   - port: 80
     targetPort: 80
     protocol: TCP
     nodePort: 30080

Ingress

  • Ingress 생성 후 이미 생성되어 있는 서비스와 연결 후 확인

JayDemy Ingress Question

Create a new Ingress resource echo in echo-sound namespace exposing Service echoserver-service on http://example.org/echo using Service port 8080.

# vi ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo-ingress
  namespace: echo-sound
spec:
  ingressClassName: nginx
  rules:
  - host: example.org
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: echoserver-service
            port:
              number: 8080

Gateway API

  • Ingress 설정을 GatewayAPI, HTTPRoute(TLS) 로 마이그레이션
  • TLS 연동 Gateway yaml

Prepium Gateway API Question

Migrate the existing Ingress web in namespace web-app to the new Gateway API. A GatewayClass named nginx is already installed. Use API version v1beta1 on this environment. Task 1: Create a Gateway named web-gateway with:

  • hostname: gateway.web.k8s.local
  • TLS termination using secret web-tls
  • GatewayClass: nginx Task2: Create an HTTPRoute name web-route with:
  • hostname: gateway.web.k8s.local
  • path prefix / -> service web-service:80
  • parentRef: the web-gateway
# vi web-gateway.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: web-gateway
  namespace: web-app
spec:
  gatewayClassName: nginx
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    hostname: "gateway.web.k8s.local"
    tls:
      mode: Terminate
      certificateRefs:
      - name: web-tls
# vi httproute.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web-route
  namespace: web-app
spec:
  parentRefs:
  - name: web-gateway
  hostnames:
  - "gateway.web.k8s.local"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: web-service
      port: 80

NetworkPolicy

  • NetworkPolicy 를 생성해서 특정 namespace 의 Pod 만 특정 경로로 연결

Prepium NetworkPolicy Question

There are two deployments, Frontend and Backend. Frontend is in the frontend namespace. Backend is in the backend namespace. Task Look at the Network Policy YAML file in /root/exam_resources. Decide which of the policies provides the functionality to allow interaction between the frontend and the backend deployments in the least permissive way and deploy that YAML.

# netpol2.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: netpol2
  namespace: backend-ns
spec:
  podSelector:
    matchLabels:
      role: backend
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend-ns
      podSelector:
        matchLabels:
          role: frontend
k apply -f netpol2.yaml

Storage 10%

PersistentVolume, PersistentVolumeClaim, StorageClass

  • PVC 생성 (PV 와 SC 는 주어짐) + kubectl edit 또는 kubectl patch 로 용량 변경
  • PV - PVC - Pod 마운트
  • volume types, access modes and reclaim policies
  • StorageClass 는 보통 docs 복붙 후 필드 수정으로 간단함

Prepium StorageClass Question

Create a new StorageClass named local-storage with the provisioner rancher.io/local-path. Set volumeBindingMode to WaitForFirstConsumer. Do not make it the default SC. Patch the StorageClass to make it the default StorageClass. Ensure local-storage is the only default class. Do not modify any existing Deployment or PersistentVolumeClaims.

# vi local-storage.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-storage
provisioner: rancher.io/local-path
volumeBindingMode: WaitForFirstConsumer
k apply -f local-storage.yaml
k patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
k patch storageclass local-storage -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

JayDemy PVC Question

A user accidentally deleted the MariaDB Deployment in the mariadb namespace, which was configured with persistent storage. Your responsibility is to re-establish the Deployment while ensuring data is preserved by reusing the available PersistentVolume. Taks: A PersistentVolume already exists and is retained for reuse. only one PV exist. Create a PVC named mariadb in the mariadb namespace with the spec:

  • Access mode ReadWriteOnce and Storage 250Mi
  • Edit the MariaDB Deployment file located at ~/mariadb-deploy.yaml to use PVC created in the previous step.
  • Apply the updated Deployment file to the cluster.
  • Ensure the MariaDB Deployment is Running and Stable.
# vi pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mariadb
  namespace: mariadb
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 250Mi
  volumeName: mariadb-pv
# vi ~/mariadb-deploy.yaml
...
template:
  volumes:
  - name: mariadb-storage
    persistentVolumeClaim:
      claimName: mariadb
  ...

Lighting Lab PV, PVC, SC Question

A new deployment called alpha-mysql has been deployed in the alpha namespace. However, the pods are not running. Troubleshoot and fix the issue. The deployment should make use of the persistent volume alpha-pv to be mounted at /var/lib/mysql and should use the environment variable MYSQL_ALLOW_EMPTY_PASSWORD=1 to make use of an empty root password. Important: Do not alter the persistent volume.

k config set-context --current -n alpha
k get pvc alpha-claim -o yaml > pvc.yaml
# vi pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-alpha-pvc
  namespace: alpha
spec:
  accessModes:
  - ReadWriteOnce         # 수정 ReadWriteMany -> ReadWriteOnce
  resources:
    requests:
      storage: 1Gi        # 수정 2Gi -> 1Gi
  storageClassName: slow  # 수정 slow-storage -> slow
k delete pvc alpha-claim
k apply -f pvc.yaml
k edit deployments.apps alpha-mysql  # persistentVolumeClaim.claimName 수정

Troubleshooting 30%

kubectl

Lighting Lab kubectl Question

Print the names of all deployments in the admin2406 namespace in the following format: DEPLOYMENT CONTAINER_IMAGE READY_REPLICAS NAMESPACE <deployment name> <container image used> <ready replica count> <Namespace>. The data should be sorted by the increasing order of the deployment name. Example: DEPLOYMENT CONTAINER_IMAGE READY_REPLICAS NAMESPACE deploy0 nginx:alpine 1 admin2406 Write the result to the file /opt/admin2406_data.

k -n admin2406 get deployments -o custom-columns='DEPLOYMENT:.metadata.name,CONTAINER_IMAGE:.spec.template.spec.containers[*].image,READY_REPLICAS:.status.readyReplicas,NAMESPACE:.metadata.namespace' > /opt/admin2406_data
  • Pod 로그 확인하여 특정 단어가 들어간 log grep 해서 파일로 저장
  • Taint 가 없는 노드 개수 파일로 저장
  • 노드 Ready 개수 파일로 저장
  • 사용률이 가장 높은 파드를 특정 label 로 조회해서 파일로 저장
  • explain 명령어로 특정 속성값 정보 파일에 저장하기

Troubleshooting

  • NotReady 상태 Ready 가 되도록 트러블슈팅
  • 보통 kubelet

JayDemy Troubleshooting Question

A kubeadm provisioned cluster was migrated to a new machine. Requires configuration changes to run successfully. Task: We need to fix a single-node cluster that got broken during machine migration. Identify the broken cluster components and investigate what caused to break those components. The decommissioned cluster used an external etcd server. Next, fix the configuration of all broken cluster components. Ensure to restart all necessary services and components for changes to take effect. Finally, ensure the cluster, single node and all pods are Ready.

k get po                                         # kube-apiserver 가 응답하지 않음
crictl ps -a | grep apiserver                    # kubectl 대신 crictl 사용
crictl logs ${apiserver=container-id}            # apiserver 로그 확인
journalctl -u kubelet -f                         # kubelet 로그에서 문제가 있는 컴포넌트 확인
vi /etc/kubernets/manifests/kube-apiserver.yaml  # 문제가 있는 부분 수정. 보통 etcd 주소가 잘못된 경우. 127.0.0.1:2379

- kubectl 안될 때 crictl ps/pod/logs/inspect

etcd

  • etcd 인증 관련 이슈
  • etcd 마이그레이션

References

Graph View

Backlinks