TRACE

<Windows Server 보안 관리 수행>

• 1. 보안 주체 식별
  On premise 환경에서는 어떤 보안 주체(사용자 및 그룹)가 어느 관리 그룹에 속할지 정해야 한다.

관리 그룹

1. Administrator
   = AD에도 있고 local에도 있다.
2. Domain Admins
   = AD DS 포리스트에 있는 모든 도메인의 Users 폴더에 위치.
   해당 구성원은 로컬 도메인 내 모든 관리 작업 수행이 가능. 
   기본적으로 로컬 도메인의 Administrator 사용자 계정만 Domain Admins에 속함.
   AD에 있는 Domain Admins가 local의 Administrator 그룹에 속하게 된다.
3. Enterprise Admins
   = AD DS 포리스트 root 도메인의 Users 폴더에 위치.
   Enterprise admins 는 하위 domain을 관리할 수 있다.
   만약 domain에 속한 각 컴퓨터 관리를 하고 싶다면 Enterprise Admins 그룹을 각 domain의 Administrator 그룹에 넣으면 된다.
4. Schema Admins
   = 스키마 수정, 삭제 권한

• 2. 최소 권한 관리
  "최소 권한" = 특정 작업이나 작업 역할을 수행하는 데 필요한 권한으로만 액세스 권한을 제한
  (적용 대상: 사용자 계정, 서비스 계정, 컴퓨팅 프로세스)
  
  
• 3. 권한 위임
  Administrator 계정에서 특정 사용자 또는 그룹에게 특정 권한을 위임한다
  제어 위임 마법사를 통해 더욱 세부적인 권한을 위임할 수있다.
  
  
• 4. PAW (Priviliged Access Workstation) 
  ID 시스템, 클라우드 서비스 및 기타 중요한 기능 관리와 같은 관리 작업을 수행하는 데 사용할 수 있는 컴퓨터
  
  
• 5. 점프 서버
  내부 네트워크와 다른 보안 영역에서 디바이스에 액세스하고 관리하는 데 사용되는 강화된 서버
  

<Windows Server 관리 도구>

• Windows Admin Center
• Server Manager
• RSAT(원격 서버 관리 도구)
• Windows PowerShell - 서버 원격 관리

실습 )
1. Windows Admin Center 설치
아래 2개의 명령어로 명령 프롬프트에서 admin center를 다운로드하고 설치한다.

-  Start-BitsTransfer -Source https://aka.ms/WACDownload -Destination "$env:USERPROFILE\Downloads\WindowsAdminCenter.msi"
-  Start-Process msiexec.exe -Wait -ArgumentList "/i $env:USERPROFILE\Downloads\WindowsAdminCenter.msi /qn /L*v log.txt REGISTRY_REDIRECT_PORT_80=1 SME_PORT=443 SSL_CERTIFICATE_OPTION=generate"

2. 접속 및 관리할 서버 추가

3. 원격 접속
왼쪽 하단의 Settings - Remote Desktop 설정을 Allow하면 원격접속이 가능하다.

4. Powershell로 Server 원격 관리

지난 시간 복습

AD(Active Directory)

주요 기능 
1. 검색 ☞ 전화번호부(전화번호 찾기가 목적), 안내표지판(건물위치를 찾기가 목적)
= "회사의 자원을 쉽게 찾기 위한 서비스"

2. 인증 ☞ A 컴퓨터에서 로그인하던, B에서 하던, C에서 하던, 미국에서 하던 싱가포르에서 하던 자신의 계정으로 로그인할 수 있고 자신이 쓰던 바탕화면을 볼 수 있음

3. Group Policy를 통한 관리 ☞ 특정 사용자에게 특정 시간에만 로그인하도록 하거나 특정 파일에 접근하지 못하도록 하는 등 사용자 그룹별로 규칙을 정하는 것

4. 3rd party 지원 

Group Policy Object(GPO)

:  AD 기반으로 되어 있는 윈도우 기반 클라이언트, 서버들을 일괄적으로 중앙에서 제어할 수 있게 하는 시스템 

:  AD DS 도메인에서 구성을 관리하며 그룹 정책 설정을 정의한다. 
:  강력한 관리 도구로, 많은 수의 사용자와 컴퓨터에 다양한 설정을 입력할 수 있다. 

:  사이트, 도메인, OU 단위로 그룹 정책을 설정할 수 있다. 

use ex) 회사 내부 진행 중인 Project Folder를 sgroup과 lgroup에만 공유하고 싶을 때, 회사 내 모든 컴퓨터의 DHCP 서비스를 중지시키고자 할 때... 

Server Manager의 'Group Policy Management' 항목을 통해 관리할 수 있다

(win 단축 명령어 : gpmc.msc)

실습) Administrator 계정으로 Projectfiles 폴더를 특정 그룹(sales)에게만 공유하는 Group Policy 

사용한 cmd 명령어
- gpresult /r : 그룹 정책 확인
- gpupdate /force : 윈도우 그룹정책 업데이트. 껐다키지 않고 수정사항 적용 
- net users : 사용자 계정 목록 보기

- set logon : 어디서 인증받았는지 알 수 있음

사용한 win+r 단축 명령어
- gpmc.msc : 그룹 정책 관리 콘솔
- services.msc : 윈도우 서비스 관리

- 주어진 범위 내에서 관리 = "Administion"
- 범위 외 관리 = "Management"

사용자 인증
- 기본 : SAM DB로 인증처리(개인)
- 중/고급 : AD로 인증처리(기업)
(SAM : lusrmgr.msc 혹은 netusers / AD : AD관리도구 를 통해 확인할 수 있다.)

AD(Active Directory) 

:  네트워크 상의 모든 리소스에 관한 정보(사용자 및 컴퓨터, 그룹 등)를 논리적 계층 구조로 중앙 저장소에 저장하여 네트워크 상에서 인증을 통해 언제 어디서라도 그 리소스를 검색하고 엑세스 할 수 있게 해주는 디렉터리 서비스 

AD를 통해 직원들에게는 편리함을 주고 관리자는 보안(사용자 인증과 접근 권한 제어)을 구현할 수 있다.

ex) AD로 도메인을 형성 → 사용자가 로그인할 때 AD에 속한 계정으로 로그인 → 별도의 인증 작업을 할 필요가 없다

AD DS(AD Domain Service)

: 사용자, 주변 장치 등의 정보를 네트워크 상에 저장하고 이 정보들을 관리자가 통합하여 관리하도록 해준다. AD DS 를 사용하기 위해선 DNS서버를 설치해야 한다.

※ AD DS를 통하여 아래와 같은 작업이 가능하다

• 앱의 설치, 구성, 업데이트
• 보안 인프라 관리
• 원격 액세스 서비스 및 DirectAccess를 사용하도록 설정
• 디지털 인증서 발급 및 관리

AD DS는 논리적 및 물리적 구성 요소를 모두 포함한다.

ⓐ 논리적 구성요소 : 조직에 적합한 AD DS 설계를 구현하는 데 사용하는 구조

• 파티션: 복제 단위
• 스키마: AD DS에서 생성되는 개체를 정의하는 데 사용하는 개체 형식 및 특성의 정의 집합
• 도메인
  : AD의 가장 기본이 되는 단위. AD가 설치된 윈도우 서버가 하나의 도메인이라고 보면 된다. 즉, 관리를 하기 위한 하나의 큰 범위 단위이다. 회사와 같은 것 
• 도메인 트리: 도메인의 집합. 부모 도메인 및 연속 DNS 네임스페이스를 공유하는 도메인의 계층 구조 집합.
• 포리스트: 두 개 이상의 트리로 AD가 구성된 것. 같은 포리스트 안의 도메인 사이에는 상호 양방향 전이 트러스트를 갖는다.(서로 신뢰)
• 조직 구성 단위(Organization Unit, OU): 조직, 부서와 같은 것. 일종의 폴더와 같은 개념(권한 위임과 그룹 정책을 적용할 수 있는 최소한의 단위)
• 컨테이너

ⓑ 물리적 구성요소 : 구체적인 개체 또는 실제 세계의 구체적인 구성 요소를 설명하는 개체

• 도메인 컨트롤러(Domain Controller, DC)
  : AD가 설치된 컴퓨터. AD 설치를 통해 도메인을 만들고 이를 운영(로그인, 이용 권한 확인, 새로운 사용자 등록, 암호 변경, 그룹 등을 처리)한다. AD DS DB의 복사본을 포함한다. DC는 변경 내용을 처리하고 도메인에 있는 다른 모든 DC에게 변경 내용을 복제할 수 있다. 회사의 대표/사장과 같은 것
  DC가 여러개 있으면 가용성이 좋고(하나가 죽어도 됨) 보안성이 좋다.
• 데이터 저장소
• 글로벌 카탈로그
  : AD 트러스트 내의 도메인들에 포함된 개체에 대한 정보를 수집하여 저장하는 통합 저장소. 
  AD를 구성하면 가상 먼저 설치하는 DC가 글로벌 카탈로그 서버로 지정된다. 글로벌 카탈로그를 사용하면 포리스트의 다른 도메인에 있는 도메인 컨트롤러에 저장되어 있을 수 있는 개체를 빠른 속도로 검색할 수 있다.
  
•  RODC(읽기 전용 도메인 컨트롤러)
  : 주 DC로부터 AD와 관련된 데이터를 전송받아 저장한 후 사용하지만 스스로 데이터를 추가하거나 변경하지는 않는다.

AD DS DB(AD DS DataBase)

: 사용자 계정, 컴퓨터 계정, 그룹과 같은 모든 도메인 개체의 중앙 저장소

Metrics Server

: Pod과 Node들의 CPU/Memory 사용량을 주기적으로 모니터링하고 metrics 정보를 수집하여 API Server에 제공

(pod Autoscaling 을 위해 반드시 필요함)

metric server 설치여부확인

-  kubectl top nodes
-  kubectl top pods -A

Metric Server 설치

-  yum install git -y
-  git clone https://github.com/237summit/kubernetes-metrics-server.git
-  cd kubernetes-metrics-server
-  kubectl apply -f .
-  kubectl get deploy -A
-  kubectl get pod -n kube-system

자원을 이용하기 위해

>> 인증(credential(ID(Account) + PW(public key, token)) → 권한허가 → Admission Controll

k8s에서는 사용자 별로 특정한 Object의 관리 범위를 설정할 수 있다. 그러므로 사용자를 생성할 수 있어야 하고, Role을 만들어 해당 User에게 RoleBinding을하고, namespace별로 context를 지정하여 해당 사용자는 제한된 업무만 하도록 해야 한다.

1) 인증-User 및 Service Account

User Account

Service Account : 백그라운드에서 실행, 애플리케이션(pod)이 실행 

kubernetes-admin : k8s의 root계정

User : cluster외부에서 k8s조작

인증서 = 인증 + 데이터 암호화
사용자는 반드시 Kubernetes cluster가 발행한 인증서가 있어야 한다. 그런 후 그 인증서를 Kubernetes API에 제공한다.

실습 ) devuser를 새로 추가해 pod만 관리하도록 

devuser 계정 생성

-  useradd devuser
-  passwd devuser
-  mkdir -p ~devuser/.kube  
-  cp -i /etc/kubernetes/admin.conf ~devuser/.kube/config
-  chown devuser:root ~devuser/.kube/config

ⓐ Private Key 생성하기

-  openssl genrsa -out devuser.key 2048
-  openssl req -new -key devuser.key -out devuser.csr -subj "/CN=devuser"
-  cat devuser.csr | base64 | tr -d "\n"

ⓑ CertificateSigningRequest 생성하기

-  wget http://down.cloudshell.kr/k8s/lab/csr-devuser.yaml : 인증서 요청 파일
-  vi csr-devuser.yaml : devuser라는 사용자를 등록

(cat devuser.csr | base64 | tr -d "\n" 했던 결과를 복사하여 request 부분에 작성한다)

ⓒ CertificateSigningRequest(CSR) 승인하기

-  k apply -f csr-devuser.yaml

-  kubectl get csr devuser -o yaml  : 사용자 추가 
-  kubectl get csr devuser -o jsonpath='{.status.certificate}' | base64 -d > devuser.crt
-  kubectl get serviceaccounts 
-  kubectl get secrets (sa의 토큰(암호)을 알 수 있음)

2) 권한 관리 - Role 및 RoleBinding (권한(role)을 만들고 이를 부여(binding)한다)

-  kubectl apply -f csr-devuser.yaml
-  kubectl get csr  : 확인
-  kubectl get csr devuser -o yaml
-  kubectl get serviceaccount

Role 생성하기-1: developer_role

-  kubectl create role developer_role --verb=create --verb=get --verb=list --verb=update --verb=delete --resource=pods

devuser는 pod에 대해서 create, get, list, update 권한을 갖고 있다.

Role 생성하기-2: sysadmin_role

-  kubectl create role sysadmin_role --verb=create --verb=get --verb=list --verb=update --verb=delete --resource=pods --dry-run=client -o yaml > sysadmin.yaml

-  kubectl apply -f sysadmin.yaml
-  kubectl get role

-  kubectl create rolebinding developer-binding-devuser --role=developer_role --user=devuser

devuser는 pod에 대해서 create, get, list, update, delete 하는 권한을 갖게 된다.

-  kubectl config view

현재 devuser에 대한 정보가 없다

-  kubectl config set-credentials devuser --client-key=devuser.key --client-certificate=devuser.crt --embed-certs=true

-  kubectl config set-context devuser --cluster=kubernetes --user=devuser

devuser를 context에 추가한다

-  kubectl config current-context

-  kubectl config use-context devuser
-  kubectl config current-context

• kubectl get pods -o wide (## 성공)
• kubectl get svc (## 실패)
• kubectl get nodes (## 실패)
• kubectl run myweb --image=nginx (## 성공)
• kubectl delete pod --all (## 성공)
권한을 부여한 대로 잘 작동한다.

kubectl cluster 구성정보 확인 및 변경방법

• 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

Pod Scheduling

: kubectl 및 yaml 파일로 Pod를 배포하라고 명령 → master의 API Server가 Master의 Scheduler로 보냄 → Scheduler가 어느 node에 Pod를 배포할 것인지를 결정 (==> 요청하는 명령 및 Node 상태에 따라)

• Pod 배정 시 특정한 Node에만 배치할 수 있다
  (nodeName, nodeSelector, nodeAffinity, podAffinity)
• 특정한 Node에는 배정하지 않도록 설정할 수도 있다
  (podAntiAffinity, Taint, cordon)
  ex) 기본적으로 master에는 Taint 설정되어 있어서 Pod이 실행되지 않음

nodeName : node 이름 사용하여 배정
nodeSelector : node 라벨 사용하여 배정
nodeAffinity : nodeSelector와 유사, 가중치 부과
podAffinity : 특정 label을 가진 Pod가 실행중인 node에 배정
podAntiAffinity : 특정 label을 가진 Pod가 실행중이지 않는 node에 배정
Cordon : 노드에 cordon 설정 시 그 노드는 Pod를 배정받지 않음
Drain : 기존에 실행중인 Pod를 뽑아내어 다른 node로 이동하고, cordon 설정이 된다.

실습 1) nodeName

-  wget http://down.cloudshell.kr/k8s/lab/pod/hostPath-2pods.yaml
-  kubectl apply -f hostPath-2pods.yaml

-  kubectl get pod -o wide

실습 2) nodeSelector
node label 지정하기 : kubectl label nodes [노드이름] [label key]=[label value]
label 조회하기 :  kubectl get node --show-labels

-  kubectl label node node1 gpu=true
-  kubectl label node node2 gpu=true
-  kubectl label node node{1,3} ssd=true

-  k get node -L gpu,ssd

---

-  wget http://down.cloudshell.kr/k8s/lab/pod/tensorflow-gpu.yaml
-  wget http://down.cloudshell.kr/k8s/lab/pod/tensorflow-gpu-replicas3.yaml
-  wget http://down.cloudshell.kr/k8s/lab/pod/tensorflow-gpu-ssd.yaml
-  kubectl apply -f tensorflow-gpu.yaml -f tensorflow-gpu-replicas3.yaml -f tensorflow-gpu-ssd.yaml

실습 3) nodeAffinity
• nodeSelector: selector field에 명시된 모든 label이 포함되어야 배정됨
• nodeAffinity: 특정 node에만 Pod이 실행되도록 유도

-  kubectl label nodes node2 disktype=ssd

-  wget http://down.cloudshell.kr/k8s/lab/pod/tensorflow-gpu-ssd-affinity.yaml
-  kubectl apply -f tensorflow-gpu-ssd-affinity.yaml

required : disktype=exist
preffered: gpu="true", disktype="ssd"
node2는 둘 다 해당되니까 weight = 20
node1은 weight = 10

weight가 더 높은 node2에 배정됨을 알 수 있다.


label 삭제하기
-  kubectl label nodes node{1..3} disktype-
-  kubectl label nodes node{1..3} gpu-
-  kubectl label nodes node{1..3} ssd-

실습 4) podAffinity
• podAffinity : pod끼리 가깝게 배치하기
• podAntiAffinity : pod끼리 멀리 배치하기


-  kubectl run backend -l app=backend --image=busybox -- sleep 9999
-  kubectl get pods -o wide --show-labels
-  kubectl get pod -o wide

-  wget http://down.cloudshell.kr/k8s/lab/pod/pod-affinity.yaml (## podAffinity)
-  kubectl apply -f pod-affinity.yaml

실습 5) nodeTaint

-  kubectl describe nodes master | grep -i taint

기본적으로 master에는 Taint 설정이 되어 있어 Pod를 배치하지 않는다.

-   kubectl taint nodes master node-role.kubernetes.io/master- (## Taint 설정 해제) >> pod 배정하여 실행함
-   kubectl taint nodes master node-role.kubernetes.io=master:NoSchedule (## Taint 설정)


-  kubectl taint nodes node1 role=web:NoSchedule (## pod 배정되지 않음)
-  kubectl describe nodes node{1..3} | grep -i taint (## Taint 설정 여부 확인)
-  kubectl taint nodes node1 role- (## 특정 node의 taint 삭제)

실습 6) cordon

-  kubectl cordon node1

-  kubectl apply -f deploy-nginx.yaml

-  kubectl uncordon node1 (## cordon 기능 해제)

실습 7) drain
drain 옵션
--ignore-daemonsets : 데몬셋이 관리하는 Pod들은 무시하고 그냥 삭제
--force : rc, rs, job, daemonset, statefulset에서 관리하지 않는 Pod까지 제거


특정 node에서 동작중인 모든 Pod을 제거

-  kubectl apply -f deploy-nginx.yaml (## 4개의 pod)
-  kubectl run pod-db --image=redis (## 따로 하나의 pod 생성)

node1의 H/W를 교체하는 일이 생겨서 실행중인 Pod를 모두 제거한 후 다시 다른 곳으로 실행하도록 하기 위해 node1을 drain한다.
-  kubectl drain node1 --ignore-daemonsets --force

drain을 하면 해당 node(node1)는 cordon이 된다.

※ 실시간으로 pod monitoring

-  kubectl get pod -o wide --watch
-  watch kubectl get pod -o wide

 Job 

:  배치 처리에 적합한 Controller로서 Pod의 성공적인 완료를 보장

:  Job을 사용하여 Pod를 실행하면?

• Pod의 작업이 정상적 종료 → 완료
• Pod의 작업이 비정상적 종료 → 다시 실행시켜 Application의 작업을 하도록 함

전제 : Kubernetes에서 Pod은 항상 Running

실습) Job
- wget http://down.cloudshell.kr/k8s/lab/job/job-exam1.yaml
- watch kubectl get pod -o wide
- kubectl apply -f job-exam1.yaml

60초 이내에 pod 종료(비정상적 종료)
- kubectl delete pod pod_name 이렇게 하면 다시 생성한다

60초 후에 Pod 보기(정상적 종료)
- kubectl get job

(application 실행이 종료되어도 Pod은 재시작하지 않음)

Job으로 만든 Pod 삭제 시 
-  kubectl delete job job_name

backoffLimit 옵션

-  backoffLimit: 10 이라면 10번까지 Pod/Container를 재시작한다(기본값6회)

restartPolicy 옵션 (비정상적 종료일 때)

• restartPolicy:Never = Pod를 재시작
• restartPolicy:OnFailure = Pod를 재시작하지 않고 Container를 재시작 (Pod 재시작 시 IP가 바뀔 수 있기 때문)

실습 1) 명령이 잘못된 Pod를 실행하는 경우 (restartPolicy:OnFailure)
-  wget http://down.cloudshell.kr/k8s/lab/job/job-exam-error1.yaml

-  kubectl apply -f job-exam-error1.yaml

▶ 이렇게 하면 6번까지 Pod이 아닌 Container가 재시작된다. 이렇게 하다가 해결되지 않으면 Pod만을 삭제한다.


실습 2) 명령이 잘못된 Pod를 실행하는 경우 (restartPolicy:Never)

-  wget http://down.cloudshell.kr/k8s/lab/job/job-exam-error2.yaml
-  kubectl apply -f job-exam-error2.yaml

▶ 이렇게 하면 Container가 아닌 Pod이 재생성된다. (여러 개의 Pod이 생성) 이렇게 하다가 해결되지 않으면 Pod만을 삭제해 버린다.

 CronJob 

:  사용자가 원하는 시간에 Job 실행을 예약하는 것

:  Job의 기능을 포함 (즉, CronJob → Job → Pod)

단지, schedule과 jobTemplate만 추가된 것이다.

:  반복해서 실행하는 Job을 운영할 때 사용 (주기적인 Data Backup, Email 전송, Log 파일 및 불필요한 데이터 삭제)

CronJob 표기법: "분 시간 날짜 월 요일"

• 분: 0~59
• 시간: 0~23
• 날짜: 1~31
• 월: 1~12
• 요일: 0~6 (일요일~토요일)
• *는 전체를 의미

예시)
매월 1일 3시 정각에 실행하라: 0 3 1 * *
주말 새벽 3시 정각에 실행하라: 0 3 * * 0,6
5분마다 반복해서 실행하라: */5 * * * *

실습) CronJob
-  wget http://down.cloudshell.kr/k8s/lab/cronjob/cronjob-exam1.yaml   

-  kubectl apply -f cronjob-exam1.yaml

성공한 Job은 3개까지 남아있는 것이 Default 값. 4번째 Job이 성공하면 첫 번째 Job은 삭제된다.
(kubectl get cronjob -o yaml로 보면 successfulJobsHistoryLimit: 3으로 되어 있다)

계속 Job이 실행되므로 CronJob을 중지하여 Job과 Pod을 삭제한다
- kubectl delete cronjobs.batch --all

Controller

: Pod를 다양한 방식으로 배포, 관리하는 기능을 수행

https://kubernetes.io/ko/docs/concepts/workloads/controllers/

 Replication Controller 

: 항상 Cluster 안에서 지정된 숫자만큼의 Pod가 동작되도록 한다

-  kubectl apply -f replicationcontroller.yaml

-  kubectl get rc,pod -o wide
-  kubectl delete pod nginx-g5wrg → 특정 pod 삭제 시 새로운 pod 생성됨

-  kubectl run myhttp --image=httpd --labels="app=nginx" --port 80
-  kubectl get rc,pod -o wide --show-labels

-  kubectl edit rc nginx → pod의 이미지, 갯수 등 다시 설정할 수 있다.


-  kubectl delete rc nginx →  Replication Controller 삭제 시 Pod도 삭제됨!!
-  kubectl delete rc nginx --cascade=orphan → Replication Controller만 삭제되고 Pod는 그대로 유지

 ReplicaSet 

: Replication Controller와 동일한 역할

차이점은 Replicaion Controller보다 더 많은 selector를 가진다는 점이다.

-  wget http://down.cloudshell.kr/k8s/lab/replicaset/replicaset-nginx.yaml
-  kubectl apply -f replicaset-nginx.yaml

-  kubectl delete -f replicaset-nginx.yaml --cascade=orphan → Pod는 그대로 남고 replicaset만 삭제됨

-  kubectl delete rs --all → 전부 삭제

 Deployment 

: Deployment는 ReplicaSet을 사용하여 Pod 개수를 조정함

: Deployment를 생성하면 자동으로 ReplicaSet과 Pod이 생성됨 (Deployment를 삭제하면 자동으로 전부 삭제됨)

: Pod의 Rolling Update 및 Rolling Back 을 위해 주로 사용

실습) Rolling Update
-  wget http://down.cloudshell.kr/k8s/lab/deployment/deployment-v1.yaml
-  kubectl apply -f deployment-v1.yaml --record (--record: 업데이트 과정을 history로 기록)
-  kubectl rollout history deployment app-deploy

-  kubectl set image deploy app-deploy myweb-con1=nginx:1.15 --record
-  kubectl get pod  → pod가 하나씩 순서대로 Update 된다
-  kubectl describe pod (pod명)

-  kubectl set image deploy app-deploy myweb-con1=nginx:1.16 --record
-  kubectl set image deploy app-deploy myweb-con1=nginx:1.17 --record

-  kubectl rollout history deployment app-deploy

-  kubectl rollout undo deploy app-deploy 

-  kubectl rollout undo deploy app-deploy --to-revision=2  → 특정 단계로 돌아간다

-  wget http://down.cloudshell.kr/k8s/lab/daemonset/daemonset-nginx.yaml
-  kubectl apply -f daemonset-nginx.yaml
-  kubectl apply -f replicaset-nginx.yaml

 StatefulSet 

:  관계를 계속해서 유지하는 것

:  즉, 관계의 상태를 유지해야 하는 application을 관리할 때 사용

:  주로 Pod의 이름 순서와 고유성을 보장하는 데 사용

:  상태를 유지하는 항목 ▶ Pod 이름을 순서대로 명명(0~N), Pod의 Volume(PVC 이름), Network (Headless Service)

※ 주의 ※ StatefulSet 생성 시 yaml 파일에는 serviceName, replicas, podManagementPolicy, terminationGracePeriodSeconds이 반드시 포함되어야 한다

-  kubectl apply -f statefulset.yaml

실습) StatefulSet의 rollingUpdate.partition 수정하기
:  StatefulSet에 변경사항이 있을 때 rollingUpdate.partition에서 지정한 값보다 작은번호의 Pod은 변경되지 않고 크거나 같은 번호만 변경시킨다
:  서버 패치할 때 등의 경우에 사용한다

-  kubectl apply -f statefulset.yaml (## web-0, web-1, web-2가 실행되고 있음)
-  kubectl edit statefulset web

-  kubectl get statefulsets.apps

 Deployment, DaemonSet, StatefulSet의 공통점과 차이점 

ⓐ 공통점

• Rolling update 및 Rollback 가능
• 각각을 삭제하면 Pod도 동시에 삭제됨

ⓑ 차이점

• Deployment
  - Pod이 어떤 Node에 생성될 지 예측 불가
• DaemonSet
  - Node별로 동일한 Pod이 하나씩 생성
• StatefulSet
  - serviceName 필요
  - Pod 이름 및 볼륨 유지
  - partition 값에 따라 업데이트 되지 않을 Pod을 지정할 수 있음

Service

• 동일한 서비스를 제공하는 여러 개의 Pod에 접근할 수 있는 하나의 IP를 제공
  (Service 자신이 갖고 있는 Selector 값과 Cluster에서 운영중인 Pod의 Label 값이 동일한 Pod으로 연결된다. Service는 자신의 EndPoint에 Pod를 추가시켜 관리한다.)

추가) kubectl run으로 pod 생성 후, Service도 생성했는데 오류가 나는 경우

→ pod의 labels 값과 service의 selector 값을 비교해볼 필요가 있다.

※ Pod의 Labels 값 확인

-  kubectl get pod -o wide --show-labels

※  Service 내부 설정 정보 확인

-  kubectl edit service 서비스명

• Service는 Pod에 연결시켜주는 Network
• 어느 Service 유형이든 결국 Cluster IP를 통해 Pod에 접근
  (Pod는 기본적으로 한 Node에서만 실행되지 않고 상황에 따라 Cluster내에 속한 여러 Node로 옮겨다닌다. 그러므로 Pod의 IP로 접속하는 데는 한계가 있고 동일한 서비스의 대표 IP인 Service의 IP로 접근하는 것이 편리하다.)

Service 종류 

1. ClusterIP

:  Default Service로서 Pod들이 클러스터 내부의 다른 리소스들과 통신할 수 있도록 해주는 가상의 클러스터 전용 IP

(IP는 Container에는 없고 Pod 에만 있다. Pod IP는 변경이 가능하므로 변경되지 않는 Virtual IP를 갖는 Service를 사용해야 한다)

:  Cluster 내에서 Pod에 접속할 때는 Cluster IP를 이용한다.(Pod는 언제든지 죽고 다시 생성되어 IP가 변경되기 때문)

:  Cluster IP로는 Cluster 내부에서만 접속할 수 있다.

:  ClusterIP → Pod

2. NodePort

: 외부에서 노드 IP의 특정 포트(<NodeIP>:<NodePort>)로 들어오는 요청을 감지하여, 해당 포트와 연결된 파드로 트래픽을 전달하는 유형의 서비스다.

: 이때 클러스터 내부로 들어온 트래픽을 특정 파드로 연결하기 위한 ClusterIP 역시 자동으로 생성된다.

: Cluster 내의 아무 Node의 IP에 대한 Port 번호로 접속하도록 한다.

(30,000 ~ 32,767 포트 사용)

:  NodePort → ClusterIP → Pod

3. LoadBalancer

:  Layer2 ~ Layer4를 지원하는 부하조정 장비 (domain은 Layer7의 Ingress Controller가 처리)

:  클라우드 공급자(Public Cloud)의 로드 밸런서, 외부 장비, Metallb를 사용하여 서비스를 외부에 노출시킨다.

:  외부 로드 밸런서가 라우팅되는 NodePort와 ClusterIP 서비스가 자동으로 생성된다.

:  OnPoremises(사내)에서는 외부 LB 장비를 이용하거나 그것보다는 k8s의 Metallb라는 Load Balancer를 이용한다.

:  로드 밸런서의 (virtual) IP를 통해 접속한다.

:  LoadBalancer → NodePort → ClusterIP → Pod

그림 출처 Google Cloud

실습 1) ClusterIP

ⓐ CLI로 ClusterIP 생성하기

-  k create deployment mygosmall --image=jesuswithme/gosmall
-  k create service clusterip mygosmall --tcp 80:80
-  k get pod --show-labels 

-  k scale deployment mygosmall --replicas=3 
-  k get svc →  clusterIP 확인
-  curl clusterIP  → 3개의 값이 랜덤으로 나옴을 알 수 있다.

ⓑ YAML로 ClusterIP 생성하기

-  wget http://down.cloudshell.kr/k8s/lab/service/nginx-deploy-clusterip-add-externalip.yaml
-  wget http://down.cloudshell.kr/k8s/lab/service/nginx-deploy-clusterip-add.yaml
-  kubectl apply-f nginx-deploy-clusterip-add-externalip.yaml  ## External IP 수동으로 지정
-  kubectl apply-f nginx-deploy-clusterip-add.yaml ## ClusterIP의 IP를 수동으로 지정
-  kubectl get pod--show-labels
-  kubectl get svc-o wide
-  curl로 clusterip에 접속해보기

실습 2) NodePort

ⓐ YAML로 NodePort 생성하기 

-  wget http://down.cloudshell.kr/k8s/lab/service/nginx-deploy-nodeport.yaml
-  kubectl apply -f nginx-deploy-nodeport.yaml (## type을NodePort로만 설정)

실습 3) Load Balancer - Metallb

※ 기초 작업
MetalLB를 위한 Namespace 생성
-  wget http://down.cloudshell.kr/k8s/namespace.yaml
-  kubectl apply -f namespace.yaml
-  kubectl get namespace : 확인

MetalLB Components 생성
-  wget http://down.cloudshell.kr/k8s/metallb.yaml
-  kubectl apply -f metallb.yaml

Metallb에 사용할 Secret 생성
- kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"

** 외부에서 접속할 때 사용되는 IP생성을 위해 ConfigMap 생성 **
-  wget http://down.cloudshell.kr/k8s/ConfigMap-Metallb.yaml
-  vi ConfigMap-Metallb.yaml (## 원하는 대역으로 수정 (기본IP 구성은 10.0.2.200-10.0.2.250인데 사내에 맞게 수정))
-  kubectl apply -f ConfigMap-Metallb.yaml 
▷ 이제 Load Balancer에 이 IP를 할당한다

ⓐ CLI로 LoadBalancer 생성하기

ⓑ YAML로 Load Balancer 생성하기

-  wget http://down.cloudshell.kr/k8s/metallb-nginx.yaml

-  kubectl create -f metallb-nginx.yaml

Pod Object 특징 
: 1개의 pod는 내부에 여러 개의 컨테이너를 가질 수 있지만 대부분 1~2개의 컨테이너를 갖는다.
= "고래(Containers)들의 떼"

: 클러스터 내에서 사용할 수 있는 고유한 IP 주소를 할당 받지만, 이 ip는 Service에서 사용하지 않는다.
: Pod의 외부에서는 'Service'를 통해 Pod에 접근한다.(Service가 Pod의 Endpoint를 관리한다.)
: Pod 내부의 컨테이너들은 네트워크와 볼륨등을 공유하고 서로 localhost로 통신할 수 있다.

실습) watch 명령어 : pod 실행 상태를 2초마다 확인한다.

-  kubectl run mypod-cli --image=nginx:1.14 --port 80
-  kubectl create deployment mypod --image=nginx:1.14 --replicas=4

여러 개의 pod를 만들고 다른 창에서 watch 명령어를 통해 상태를 확인한다.

• 동작중인 Pod 확인하기

- kubectl get pod -o wide
- kubectl get pod -o yaml
- kubectl get pod -o json

실습) 하나의 Pod에 여러개의 Container가 동작하는 Pod 생성

 

그 이유는, 같은 pod에 위치한 또 다른 컨테이너인 nginx container와 IP(네트워크)를 공유하기 때문이다.

Pod Life Cycle 단계

• Pod의 Life Cycle은 Pod의 생성에서 삭제까지의 과정을 말한다

• Pending ➔Running ➔Succeeded/Failed ➔Unknown

• Pod의 생명주기를 구체적으로 보기 위해서 describe의 status와 type을 참고하면 된다

- kubectl get pod -o wide --watch : 실시간 생명 주기 확인

-  Troubleshooting

• Pod를 생성하는데 실패하였다면 어느 단계에서 문제가 있었는지 알 필요가 있다

• 이럴때 kubectl describe pod pod_name을 실행한다