앵앵

### ns lookup
kubectl run test-nslookup --image=busybox:1.28 --rm -it --restart=Never -- nslookup <domain>


### curl test 
kubectl run curl --image curlimages/curl -it /bin/sh

□  json 자료 유형

 - [] – array

 - {} – dictionary

□  json을 활용한 kubectl query 

(출처: kubectl Cheat Sheet | Kubernetes)

#Query1
kubectl get pod -o jsonpath='{$.items[*].metadata.name}{“\n”}’

#result
busybox-1 busybox-2

#Query2
kubectl get pod -o jsonpath='{$.items[*].spec.containers[?(@.image == "busybox:latest")].name}{"\n"}’


#result
busybox-1 busybox-2

결과는 같지만, Query1/Query2가 가져오는 key:value  다르다.

배열의 모든 값 “*” (wild card),  조건식 “?()”  (='{$.items[*].spec.containers[?(@.image == "busybox:latest")].)  은 다음에..

출처 : 서비스 및 파드용 DNS | Kubernetes

- 중요

- Pod 의 DNS 주소를 확인 방법

   위의 설명을 보면, Pod는 <pod-ip-address>를 dns 주소로 같는다고 했으므로,

   "1) Pod의 IP주소 확인,  2) Pod IP에  nslookup "  순서로 확인 한다.   

□ Pod 의 DNS 주소를 확인 예시

   1) Pod의 IP주소 확인

  - -o wide 옵션으로  Pod의 IP를 확인

2) Pod IP에  nslookup 

 .  Pod IP는  "." 을 "-"로 대체하여 사용하면 됩니다.

kubectl exec -it busybox -- nslookup 192-168-1-16.default.pod.cluster.local

<Pod에  nslookup 성공>

  . Pod name을 사용할 경우 ( 실패한다) 

<Node Drain 실패>

controlplane ~ ➜  kubectl drain node01 --ignore-daemonsets
node/node01 cordoned
error: unable to drain node "node01" due to error:cannot delete Pods declare no controller (use --force to override): default/hr-app, continuing command...
There are pending nodes to be drained:
 node01
cannot delete Pods declare no controller (use --force to override): default/test-app

There are pending nodes to be drained:
 node01
cannot delete Pods declare no controller (use --force to override): default/hr-app

- 원인 : Drain을 하기 위해선 1개 이상의 Replicaset이 있어야 함.

             즉 deploy,replicaset 으로 replica를 1개 이상 유지 시킬 object가 필요한것이다. 

- 조치 :  1) Pod를   deploy, replicaset으로 바꿔주던지, 

              2) 아니면   " --force " 옵션으로  pod를 영원히 날려버리던지 

              ex) kubectl drain node01 --ignore-daemonsets --force

ㅁ 각 위치별 security context 적용 범위 

Pod는 컨테이너를 담는 보자기? 그릇? 정도로 이해하면 빠를것 같다.

Pod 스펙  (yaml의 빨간색 부분)에 securityContext를 적용했다면 

Pod(보자기) 內 에 모든 컨테이너들이 적용을 받는 것이 맞지만,

컨테이너 스펙 에  SecurityContext( yaml파란색 부분)가 또 있다면,  

파란색 부분(runAsUSer:1002)를 적용 받는다. 

요약하면

- 빨간색 SecurityContext의 적용 범위 :   Container2(name:abc)  , Container3 (name:def)

- 파란색 Security Context의 적용 범위 :  Container1(name:web)

apiVersion: v1
kind: Pod
metadata:
  name: multi-pod
spec:
  securityContext:
    runAsUser: 1001
  containers:
  -  image: ubuntu
     name: web
     command: ["sleep", “300"]
     securityContext:
      runAsUser: 1002

  -  image: ubuntu
     name: abc
     command: ["sleep", " 300"]

 -  image: ubuntu
     name: def
     command: ["sleep", " 300"]

※ 참조yaml

□ 신규 인증서 생성,승인 이걸 하는 이유?

 - k8s는 tls 기반으로 각 component에 엑세스를 하기때문에,  새로 추가된 멤버(개발자)에게 k8s 접근하기 위해선 ceriticate을 필요함.

□ 순서 

# key 생성
[node2 pki]$ openssl genrsa -out tam.key 2048
Generating RSA private key, 2048 bit long modulus
...................+++
.....+++
e is 65537 (0x10001)

 - csr파일 생성

## csr파일 생성,   "CN=tam" (CN은  하고싶은대로 하면 됨) 
[node2 pki]$ openssl req -new -key tam.key -subj "/CN=tam" -out tam.csr
[node2 pki]$ cat tam.csr
-----BEGIN CERTIFICATE REQUEST-----
MIICUzCCATsCAQAwDjEMMAoGA1UEAwwDdGFtMIIBIjANBgkqhkiG9w0BAQEFAAOC
<중략>
-----END CERTIFICATE REQUEST-----

2. k8s에 csr object 생성( .yaml작성)

  ① :   "CN=tam" 으로 생성했기때문에,  name: tam으로 하면 됨

  ② : request 값은   tam.csr을 base64 encoding 한 값을 넣으면 됨 

  -> tam.csr을 base64 encoding  은   base64 -w 0 명령으로 한줄로 뽑으면 편함

### base64 인코딩 한줄로 출력

[node2 pki]$ cat tam.csr | base64 -w 0
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVN

ex) csr.yaml 작성예시 

### vi로  yaml 파일 작성
vi tam-csr.yaml

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: tam
spec:
  request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1V6Q0NBVHNDQVFBd0RqRU1NQW9 <중략>  
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 86400  # one day
  usages:
  - client auth

3. k8s에 csr 승인

   ex) 

## create csr 
[node2 ~]$ kubectl apply -f tam-csr.yaml 
certificatesigningrequest.certificates.k8s.io/tam created




## 생성된 csr 확인 
[node2 ~]$ kubectl get csr
NAME   AGE   SIGNERNAME                            REQUESTOR          CONDITION
tam    35s   kubernetes.io/kube-apiserver-client   kubernetes-admin   Pending
 
## csr 승인 
[node2 ~]$ kubectl certificate approve tam   
certificatesigningrequest.certificates.k8s.io/tam approved

출처 : certified-kubernetes-administrator-course/06-TLS-in-Kubernetes.md at master · kodekloudhub/certified-kubernetes-administrator-course (github.com)

K8s의 TLS(openssl사용) 구성은 크게 3가지로 분류 한다

모두 최상위 인증(ROOT CA)가 “Issuer: CN = Kubernetes” 이고, “Subject: CN”은 Certificates 마다 다름.

□ CERTIFICATE AUTHORITY(CA)  - 최상위 인증 (ROOT CA)

 - Ca.crt, Ca.key

 - Ca.crt를 통해 인증한 *.crt파일을 생성 한다

   ex) openssl x509 –req in xxx.csr –CA ca.crt –Cakey ca.key –out xxx.crt

□  Client Certificates

 - admin.crt, kube-scheduler.crt, controller-manager.crt, kube-proxy 등

□ Server Certificates for Servers

 - etcd-server,api-server,kubelet server

각 Certificate의 CN/만료일 정보는 아래와 같다.

#sample 
openssl x509 -in <인증파일> -noout -text

#example
cd /etc/kubernetes/pki;      
openssl x509 -in ca.crt -noout -text

아래 그림을 보면   각 인증서 별로  "Issuer: CN = kubernetes"로 같지만,   "Subject: CN"은 component별로 다르다는 것을 확인 할 수 있다.

## helm 리스트
helm list

##helm repo list & update 

helm repo

helm repo list


helm repo update

## helm rollback

helm list

helm histroy <release-name>

helm rollback <release-name> <history-revision>

# helm delete 
helm delete <release-name> --purge

Failed to get system container stats for "/system.slice/kubelet.service": failed to get cgroup stats for "/system.slice/kubelet.service": failed to get container info for "/system.slice/kubelet.service": unknown container "/system.slice/kubelet.service"

ㅁ 조치( To slove this event)

 - docker,kubelet restart

(root user)
systemctl stop kubelet;systemctl stop docker;
systemctl start kubelet;systemctl start docker;

- 발생이벤트
kubelet:E0300 20:45:31.395023 0532 kubelet_volumes.go: 154] orphaned pod "23fww56c-2012-45xv-k124-452395be2792" found, but volume paths are still present on disk.

#상세조회
kurnalctl -f -u kubelet

- 원인 : Pod가 삭제된 상태에서 node 이슈(hang,shutdown)으로  node에서 pod 디렉토리가 삭제되지 않음

- 조치 : Pod가 사용하던 디렉토리 삭제해주면 됨

. 삭제된 Pod의 디렉토리 조회 : ls -l /var/lib/kubelet/pods/23fww56c-2012-45xv-k124-452395be2792

  (ls -l /var/lib/kubelet/pods{UID}

. 디렉토리  삭제 : rm -rf /var/lib/kubelet/pods/23fww56c-2012-45xv-k124-452395be2792

※ 삭제가 안될경우는 볼륨해제 후 rm 실행

mount | grep {UID}xxxxx
umount /var/lib/kubelet/pods{UID}xxxxxxx