<aside> 💡 Pod 스케줄링 및 인증과 권한 관리

<aside> ❓ Pod Scheduling?

kubectl 및 yaml 파일로 pod을 배포하라고 명령을 하면 master의 API Server가 그 명령을 Master의 Scheduler가 어느 node에 Pod을 배포할 지 결정, 예약함.
Pod을 특정한 Nod에 배치할떄

→ nodeName, nodeSelector, nodeAffinity, podAffinity, Cordon(지금부터 pod 배정을 안받는), Drain(실행중인 모든 Pod를뽑아내어 다른 node로 이동)
특정한 Nod에 배치하지 않을 때

→ podAntiAffity, Taint, cordon

</aside>

<aside> 💳 nodename

</aside>

<aside> 💳 nodeSelector

# gpu,ssd label지정
k label node node1 gpu=true
k label node node2 gpu=true
k label node node{1,3} ssd=true

# gpu,ssd, label 삭제
kubectl label nodes node{1..3} disktype-
kubectl label nodes node{1..3} gpu-

k get node -L gpu,ssd
k get node --show-labels

# gpu=true인 node에서만 작동
kubectl apply -f tensorflow-gpu.yaml -f tensorflow-gpu-replicas3.yaml -f tensorflow-gpu-ssd.yaml

</aside>

<aside> 💳 Affinity & antiAffinity

<aside> 💳 node Affinity == weight을 줘서 배정한다

kubectl label nodes node2 disktype=ssd

kubectl label -L gpu,disktype

# tensorflow-gpu-ssd-affinitiy.yaml
apiVersion: v1
kind: Pod
metadata:
  name: tensorflow-gpu-ssd-affinity
spec:
  containers:
  - name: tensorflow
    image: tensorflow/tensorflow:nightly-jupyter
    ports:
    - containerPort: 8888
      protocol: TCP
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - {key: disktype, operator: Exists}
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 10
        preference:
          matchExpressions:
          - {key: gpu, operator: In, values: ["true"]}
          - {key: disktype, operator: In, values: ["ssd"]}

</aside>

<aside> 💳 Pod Affinity

Pod Scheduling podAffinity: pod을 더 가깝게 배치하기 ex: wordpress 파드와 mysql 파드를 같은 node에 배치할 것을 요구
podAntiAffinity: Pod을 더 멀리 배치하기 ex: Database인 mysql 파드와 redis 파드를 다른 node에 할당할 것을 요구
podAffinity 요구 조건 필수 요구: requiredDuringSchedulingIgnoreDuringExecution 선호도 요구: preferredDuringSchedulingIgnoreDuringExecution
topologyKey node label을 이용해 pod의 Affinity와 antiAffinity를 설정할 수 있는 또 하나의 기준 k8s는 Pod을 스케줄링할 때, 먼저 pod의 label을 기준으로 대상 node를 찾고, 그 이후 topologyKey 필드를 확인해 해당 node가 원하는 node인지 확인한다 </aside>

<aside> 💳 Node taint(오염)

# Taint 설정 해제
kubectl taint nodes master node-role.kubernetes.io/master-

# Taint 설정
kubectl taint nodes master node-role.kubernetes.io/master=master:NoSchedule

# Taint 확인
kubectl describe nodes master | grep Taints

Effect 필드 종류
- NoSchedule
  
  → toleration이 맞지 않으면 배치되지 않는다
- PreferNoSchedule
  
  →toleration이 맞지 않으면 배치되지 않으나, cluster의 resource가 부족하면 할당된다.
- NoExecute
  
  → toleration이 맞으면 동작중인 Pod을 종료한다

# node1 taint 확인
k describe nodes node1 | grep -i taint

# node1~3 taint 확인
k describe nodes node{1..3} | grep -i taint

</aside>

<aside> 💳 cordon(저지선)

# node2에 cordon 설정
k cordon node2

# pod배포
kubectl apply -f deploy-nginx.yam
-> 설정한 node2에서는 pod배포 안함

# node2에 cordon 설정해제
k uncordon node2

</aside>

<aside> 💳 drain(물 빼기)

특정 Node에서 동작중인 모든 Pod을 제거.
option
- --ignore-daemonsets: 데몬셋이 관리하는 Pod들은 무시하고 그냥 삭제
- --force: rc, rs, job, daemonset, statefulset에서 관리하지 않는 Pod까지 제거

# deployment로 4개의 pod 실행
kubectl apply -f deploy-nginx.yaml

# pod 1개만 실행
kubectl run pod-db --image=redis

# pod 1개만 이 실행되고 있는 node에 drain적용
kubectl drain node3 --ignore-daemonsets --force
-> pod 1개만 실행되는건 삭제되고 재실행이 안되지만 deployment로 생성된건 다른 node에 자동으로 재생성된다.

</aside>

<aside> 🔒 인증과 권한 관리

<aside> 🗣 API요청(Request) 처리과정

kubectl get nodes

인증(Authentication) → 권한점검(Authorization) → 요청승인(Admission Control)
- 인증 : User(인증서)/Group, Service Account(토큰)
- 권한 : Role/RoleBinding, ClusterRole/ClusterRoleBinding

# 사용자 확인
kubectl config view
----------------------------------------------
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: <https://10.0.2.20:6443>
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    **user: kubernetes-admin**
  **name: kubernetes-admin@kubernetes**
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
----------------------------------------------

k8s cluster에서의 User Account

# Account 만들기
useradd devuser
passwd devuser

# 관리자에게 권한 주기
su - root
mkdir -p ~devuser/.kube
cp -i /etc/kubernetes/admin.conf ~devuser/.kube/config
chown devuser:root ~devuser/.kube/config
su - devuser
-> **성공**

user를 생성하기 위해
1. Private key 생성하기
2. CertificateSigningRequest 생성하기
  - csr-devuser.yaml이라는 인증서 파일 생성하여 k8s에서 devuser라는 사용자 등록
3. CertificateSigningRequest(CSR) 승인하기

# Normal User 생성하기
**인증 + 데이터 암호화

# private key만들기
openssl genrsa -out devuser.key 2048
-----------------------------------------------------------
-rw-r--r--  1 root root 1675  7월 25 14:23 devuser.key
-----------------------------------------------------------

# 인증서 만들기
openssl req -new -key devuser.key -out devuser.csr -subj "/CN=devuser"
-----------------------------------------------------------
-rw-r--r--  1 root root  887  7월 25 14:24 devuser.csr
-----------------------------------------------------------

# 인증용 yaml 파일 다운
wget <http://down.cloudshell.kr/k8s/lab/csr-devuser.yaml>

# 처음부터 =까지 복사 --> 인증서 내용 key
cat devuser.csr | base64 | tr -d "\\n"

# vi csr-devuser.yaml request에 추가.
----------------------------------------------------------------------------------------------------------------------
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: devuser
spec:
  request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1Z6Q0NBVDhDQVFBd0VqRVFNQTRHQTFVRUF3d0haR1YyZFhObGNqQ0NBU0l3RFFZSktvWklodmNOQVFFQgpCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFONkxWQklRNkNIR1Fiejkxc1gwd2tjcW1mc3M5elBNaHFrK2NrWkV0aUVWCnh6YXBqVVF6bWEwTytSTDJmTXJsRDEyeWp6Qk8rMWQ3QTR4a1hJcTF5NmxQRUU0amw2UEhpcHB6b29RWVh1MzcKV3NzVmttKzl3MU9vcVlST2JTa1dNODlIZDJRT2d3OHptL0ZaRWtnWEJLRGxXeHhjNkV6bHFxcW5MVDVkNmEyMgpYY09ORytNSFBRTDNJbmJ3VEgxR3duWnJCOHNxZ3pPYVVOOG9vdUZOUHBlK2krdUZIcFpYUHpTMjZ0aVlxMXhrCkhveFd1dFBIMUNqVEhjUjl4Skk5bWtxYzI4YjZRR1VoZ0R3WGZzWjJyeXhOd1JmNmJGTHpsZWxDd0R4MHJmdXAKWGxtVGROMDh2UG9mM1NpS1IwU3VtMWpveU84S3dZYlE5Zi9PdVBTTmtWa0NBd0VBQWFBQU1BMEdDU3FHU0liMwpEUUVCQ3dVQUE0SUJBUUFGSWJ0ZDgrZ3Z0QnJvR0VFTUk1Wi95WXVwaDk4aFRRSTNuamZRRmF0Z0tzeElPMCtUCkpKeFJtTUswM29tQmtJVUI1MTcrc296L0pKdE5oeFp4NlBodklPbE5yRmVhZCtFcW9QVkxuZkpTR3BHRDVQYXAKN1J0Y0lQYjIrejVHQWhKZ0wyMVhOOVllK0VGWkhua3lES0VJWE5ETFAyamtlNVovend3OEVIVHd5T2NvMDRGQwpZMHpBQjZVS0szMVpDZHZSM0ZkcDl6aitCcC81VXpraHRESTNyWjBMTGJhSWRoOGZlaEFlbnBlc0xlck9kbzBuClorKzlJekhYWUFnS2ltTThkaEtmYm1UZXB0YVZ1bFNEUXRpa0RQakVGeStqN3hkcDBvOUMyRkFKNmVtUUJZck0KSEJjWDBBc0twRGQwTmNsL1lVSlVkRW91QURKR0ZNVzNVTmhLCi0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth
----------------------------------------------------------------------------------------------------------------------

# 인증용 yaml파일 적용
kubectl apply -f csr-devuser.yaml

# 현재 상태 확인
kubectl get csr

# pending 중지 를 approved 승인
kubectl certificate approve devuser

# 인증서요청파일을 인증파일로 저장
## .crt: 인증파일 .csr: 인증서요청파일 .key: 키 
kubectl get csr devuser -o jsonpath='{.status.certificate}' | base64 -d > 
devuser.crt
-----------------------------------------------------------
-rw-r--r--   1 root root  1090  7월 25 14:35 devuser.crt
-----------------------------------------------------------**

Service Account

Pod이 실행될 때 특별히 Service Account를 설정하지 않으면 namespace에 default라는 ServiceAccount가 할당된다


kubectl get serviceaccounts
kubectl get secrets

kubectl run testpod --image=nginx
kubectl get pod testpod -o yaml | grep -i serviceAccout

kubectl create serviceaccount pod-viewer

Role 요약

k8s 에서는 사용자별로 특정한 Object의 관리 범위를 설정할 수 있다.
kubectl config
- kubectl config view
- kubectl config get-contexts
- kubectl config set-context devuser --cluster=kubernetes --user=devuser
- kubectl config use-context devuser (##현재 context 지정하기)
- kubectl config current-context
- kubectl config use-context kubernetes-admin@kubernetes
- kubectl config get-contexts (## * 가 현재 context이다)
- kubectl config current-context </aside>

</aside>

<aside> ⚙ Kubernetes Autoscaling

Pods layer Autoscalers
- HPA(Horizontal Pod Autoscaler)
- VPA(Vertical Pods Autoscaler)

<aside> 💡 Horizontal Pod Autoscaler(HPA)

Metrics Server가 반드시 존재해야함
- Metrics Server는 각 Pod과 Node의 사용량을 모니터링하여 API를 통해 볼 수 있게 함

<aside> 💡 Metrics Server

kubectl top 명령어로 확인

Metric Server 설치

# git 설치
yum install git -y
git clone <https://github.com/237summit/kubernetes-metrics-server.git>

# metric server 실행
cd kubernetes-metrics-server
kubectl apply -f .
kubectl get deploy -A
kubectl get pod -n kube-system

****kubectl top nodes
kubectl top pods -A

CPU 기반의 HPA 운영

**# k8s 폴더에서 작업**
wget <http://down.cloudshell.kr/k8s/lab/hpa/deploy_web_for_hpa.yaml>
kubectl apply -f deploy_web_for_hpa.yaml
kubectl get all

**# Pod의 CPU 사용량이 50% 이상 올라가면 Pod을 1개에서 10개까지
확장하기-작업 부하 증가시키기**
wget <http://down.cloudshell.kr/k8s/lab/hpa/hpa_web.yaml>
kubectl apply -f hpa_web.yaml
****kubectl get hpa

</aside>