앵앵

ㅁ 각 위치별 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

출처 : https://kubernetes.io/docs/reference/kubectl/cheatsheet/

ㅁ Pod/Deploy 사용중인 이미지 조회 (  Pod/Deploy's image tag) 

## Pod별 
kubectl get pod -n kube-system -o=custom-columns=podname:metadata.name,namespace:metadata.namespace,image:spec.containers..image

## deploy 별
#여러줄
kubectl get deploy -n kube-system --no-headers -o=custom-columns\
=deployname:metadata.name,name-space:metadata.namespace,\
image:.spec.template..spec.containers..image

## deploy 별
#한줄
kubectl get deploy -n kube-system --no-headers -o=custom-columns=deployname:metadata.name,name-space:metadata.namespace,image:.spec.template..spec.containers..image

## daemonset

ㅁ Header 제거 ( no-headers) 

kubectl get ns --output=custom-columns=:.metadata.name --no-headers

ㅁ  pod 시작시간 정렬 (sort by pod's startTime) 

kubectl get pod -A --sort-by=.status.startTime

ㅁ node,ip hostname ( k8s nodes' ip/hostname)

kubectl get nodes -o jsonpath='{.items[*].status.addresses[*].address}'

ㅁ secret의 base64 decode 

kubectl -n kubernetes-dashboard get secret dashboard-admin-secret -o go-template="{{.data.token | base64decode}}"