섹션6: Cluster Maintenance
- cluster upgrade 할 때
pod upgrade 및 backup & recover kubernetes cluster
119. OS Upgrades
OS upgrade를 해야 할 경우, replicaset 이 설정된 pod는 다른 node로 옮겨진다.단일 pod인 경우에는 서비스가 안된다.
이럴경우 pod를 다른 node로 옮긴 후 대상 node를 업그레이드한다.
- cordon : pod를 다른 node로 옮기지 않는다.
- drain : pod를 다른 node로 옮긴다.
kubectl cordon $NODENAMEnode를 drain 한다.(pod를 다른 node로 옮긴다.)
kubectl drain $NODENAME --ignore-daemonsets다시 node를 scheuling 상태로 변경한다.
kubectl uncordon $NODENAME
122. Kubernetes Software Versions
kubectl get nodes 의 VERSION 항목 : v1.24.1
- v1: major version, 24: minor version, 1 : patch version
alpha -> beta -> stable 버전
kube-apiserver, kube-controller-manger, kube-scheduler, kubelet, kube-proxy, kubectl 은 같은 버전
etcd, coreDNS는 버전이 다름.
124. Cluster Upgrade Process
모든 컴포넌트가 같은 버전이어야 하는가? 그렇지는 않다. 단, apiserver 버전보다는 높을 수 없다.
그러나, kubectl 은 apiserver 버전보다 한단계 높을 수 있다.
Kubernetes supports only up to the recent three minor versions.
Kubernetes는 최신 3개의 마이너 버전까지만 지원합니다.
master node upgrade
- 마스터 노드 업그레이 동안 마스터 노드의 컴포넌트를 사용할 수 없는 상태가 된다. 그러나 worker node의 pod 는 사용할 수 있다. kubectl 로 master node에 접근할 수 없다. upgrade가 완료되면 정상적으로 작동한다.
worker node upgrade
방법1) downtime을 가지고 worker node 전체를 업그레이드 한다.
방법2) worker node 한대씩 업그레이드 한다.
방법3) 업그레이드된 worker node 를 추가하여 node를 교체한다.
* kubeadm upgrade
- kubeadm upgrade plan
- kubeadm upgrade apply
=> kubeadm은 kubelet을 업그레이드하지 않는다. kubeadm을 업그레이드 한 후 kubelet을 업그레이드한다. kubelet을 재시작한다.
----------------- upgrade 순서 --------------
kubeadm upgrade -> kubernetes component upgrade(apiserver, scheduler 등) -> kubelet upgrade
128. Backup and Restore Methods
- resource configuration : files, GitHub로 저장, kubeapi
- ETCD Cluster : data directory(etcdctl snapshot save snapshot.db 명령어로 백업, etcdctl snapshot restore snapshot.db --data-dir=/backup-dir)
- Persistent Volume
섹션7: Security
136. Kubernetes Security Primitives
- Network Policies
137. Authentication
Accounts
139. TLS Introduction
141. TLS in Kubernetes
151. API Groups
152. Authorization
153. Role Based Access Controls
<<here>>
155. Cluster Roles and Role Bindings
섹션8: Storage
- storage drivers
- volume drivers
169. Storage in Docker
- File System
- Layered architecture
storage deivers : AUFS, ZFS, BTRFS, Device Mapper, Overlay, Overlay2
170. Volume Driver Plugins in Docker
volume driver : local, Azure File Storage, Convoy, DigialOcean Block Storage, Flocker, gce-docker, GlusterFS, NetApp, RexRay, Portworx, VMware vSphere Storage
171. Container Storage Interface (CSI)
173. Volumes
vloume Types : Directory(standalone node),
storage type solution : KFS, ClusterFS, Flocker, ceph, SCALEIO, AWS ebs, GCP, Azure
173. Persistent Volumes
스토리지를 중앙에서 관리하고자 할 때, 관리자가 대규모 스토리지 풀을 생성해서 관리합니다.
그런 다음 사용자가 필요한 스토리지를 사용하도록 합니다.
이것이 영구 볼륨이 필요한 이유입니다.
173. Persistent Volume Claims
노드에서 스토리지를 사용할 수 있도록 영구 볼륨 클레임을 생성합니다. 영구 볼륨 및 영구 볼륨 클레임은 Kubernetes 에서 두 개의 개별 오브젝트입니다.
관리자가 영구 볼륨 세트를 생성하고 사용자가 영구 볼륨 클레임을 생성하여 영구 볼륨을 사용합니다.
PVC & PV -> Binding(1:1)
PVC를 삭제할 때 PV는 PV policy 에 따름(Retain, Recycle, 그리고 Delete가 있다)
PVC를 생성하고 나면 다음과 같이 볼륨 섹션의 PersistentVolumeClaim 섹션에서 PVC 클레임 이름을 지정하여 POD 정의 파일에서 사용합니다.
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: myfrontend
image: nginx
volumeMounts:
- mountPath: "/var/www/html"
name: mypd
volumes:
- name: mypd
persistentVolumeClaim:
claimName: myclaimReplicaSets or Deployments 도 동일합니다. Deployment on ReplicaSet의 template section 에 PVC를 정의합니다.
- HostPath: 볼륨 자체에는 scheduling 정보가 포함되어 있지 않습니다. 노드의 각 포드를 수정하려면 해당 포드에 대해 nodeSelector와 같은 scheduling 정보를 구성해야 합니다.
- Local: 볼륨 자체에는 scheduling 정보가 포함되어 있으며 이 볼륨을 사용하는 포드는 특정 노드에 고정되어 데이터 연속성을 보장할 수 있습니다.
- volumeMounts: 의 name:은 volume 에서 정의한 name: 값을 사용해야 합니다.
- PVC를 사용하는 pod가 있을 때는 삭제 시 pending 상태가 됩니다.
181. Storage Class
pod에 스토리지 연결 : PV -> PVC -> Volumes -> VolumeMounts
만일, google 의 스토리지를 연결하려면 ?
SC -> PVC -> Volumes -> VolumeMounts
Dynamic Provisioning
apiVersion: storage.k8s.io/v1
king: StorageClass
섹션9: Networking
<<HRRE>> START(22.06.28)
185. Prerequisite - Switching Routing
switching & routing
- switching
- routing
- gateway
185. Prerequisite - Switching Routing
- ip link
- ip addr add 192.168.1.10/24 dev eth0
- ip addr add 192.168.1.11/24 dev eth0
Switching : 같은 네트워크에서 통신할 수 있도록 해주는 장비
Routing : 같은 네트워크에서 통신할 수 있도록 해주는 장비
ip route add 192.168.2.0/24 via 192.168.1.1 은 192.168.2.0/24 과 통신하기 위해서는 192.168.1.1 를 통하라 라는 의미임.
네트워크 인터페이스가 하나이면 default gateway만 있으면 되지만, 네트워크 인터페이스가 2개 이상인 경우에는 각각 gateway를 설정할 수 있다. 아래 그림에서 C 서버는 192.168.2.1로 설정되어 있고, D 서버는 192.168.2.2 로 설정된 경우 C 서버는 인터넷과 연결되지만 D 서버는 연결되지 않는다.
186. Prerequisite - DNS
DNS 서버
DNS
- DNS Configuration on linux
- CoreDNS
Networkn namespace
Docker Networking
/etc/hosts
* 관리하는 대상 서버들이 많을 경우 hosts 파일로 서버명을 관리하는 것은 비효율적임(IP가 변경되거나 서버가 추가되면 모든 서버의 hosts 파일을 변경해줘야 함). 그래서 하나의 서버에서 관리하는 개념이 DNS 서버임.
/etc/resolv.conf(search, nameserver 설정)
/etc/nsswitch.conf
name으로 host를 찾는 순서는 기본적으로 hosts 파일 -> DNS 서버 순서임. 그러나 nsswitch.conf 파일에서 순서를 변경할 수 있음nsswitch.conf 는 /etc 디렉토리 밑에 있으며 파일안의 hosts 항목을 hosts: dns files 로 변경하면 hostname을 찾을 때 dns 서버 먼저 찾고 없을경우 local 서버의 hosts 파일을 찾는다.
관련 명령어 : nslookup, dig
187. Prerequisite - CoreDNS
설치
coredns는 hosts 파일 또는 Corefile을 참조한다.
188. Prerequisite - Network Namespaces
집을 비유하면 host는 집이고 Network Namespaces는 각각의 방으로 생각하면 됨.
컨테이너는 namespace로 구분된다. 컨테이너 각자는 routing table과 ARP table을 가지고 있다.
linux에서 network namespace 생성
- ip netns add red
- ip netns add blud
ip netns 로 확인
container의 interface를 확인
ip netns exec red ip link(ip -n red link 도 동일)
컨테이너에 IP 할당
1) 가상 인터페이스 추가 : ip link add veth-red type veth peer name vech-blue
2) 가상 인터페이스를 네임스페이스에 할당 : ip link set veth-red netns red
3) 가상 인터페이스를 네임스페이스에 할당 : ip link set veth-blue netns blue
4) IP 할당 : ip -n red addr add 192.168.15.1 dev veth-red
5) IP 할당 : ip -n blue addr add 192.168.15.2 dev veth-blue
6) ip -n red link set veth-red up
6) ip -n blue link set veth-blue up
두 개의 컨테이너가 통신가능
ip netns exec red ping 192.168.15.2
여러개의 컨테이너가 있을 경우 가상 스위치를 설치한다.
- 가상스위치 : LINUX Bridge, Open vSwitch
가상스위치 설정 방법(Linux Bridge)
ip link add v-net-0 type bridge
While testing the Network Namespaces, if you come across issues where you can't ping one namespace from the other, make sure you set the NETMASK while setting IP Address. ie: 192.168.1.10/24
ip -n red addr add 192.168.1.10/24 dev veth-red
Another thing to check is FirewallD/IP Table rules. Either add rules to IP Tables to allow traffic from one namespace to another. Or disable IP Tables all together (Only in a learning environment).
190. Prerequisite - Docker Networking
191. Prerequisite - CNI
쿠버네티스 사이트에서 weavenet CNI 를 설치하는 명령어가 있는 url.( CKA 문제 중 클러스터를 구성하라는 문제가 나올 경우 CNI를 설치해야 하는데 쿠버네티스 웹페이지의 설치 문서에는 명령어가 없고 외부 url과의 링크만 되어 있다. 시험에서는 쿠버네티스 웹페이지 이외에는 접속할 수 없다. 아래 URL 접속 경로를 잘 익혀서 시험에 활용한다.
참고로 (2022.06.29 현재) 시험제도가 조금 변경되어서 즐겨찾기를 이용할 수 없다.
ip a | grep -B2 10.13.214.10
* -B + number : 숫자만큼 이전 라인수를 보여준다.
196. Pod Networking
Networking Model
- Every POD should have an IP address
- Every POD should be able to communicate with every other POD in the same node
- Every POD should be able to communicate with every other POD on other nodes without NOT.
197. CNI in kubernetes
- container runtime must create network namespace
- Identify network the container must attach to
- container runtime to invoke network Plugin(bridge) when container is ADDed
- container runtime to invoke network Plugin(bridge) when container is DELeted
- JSON format of the network configuration
198. CNI weave
201. Practice Test - Deploy Network Solution
203. IP Address Management - Weave
206. Service Networking
209. DNS in kubernetes
210. CoreDNS in Kubernetes
섹션10: Design and Install a kubernetes cluster
221. Design a Kubernetes Cluster
222. Choosing Kubernetes Infrastructure
- local host
- minikube
- kubeadm
Turnkey solution
- OpenShift : CI/CD
- Cloud Foundry Container Runtime
- VMWare Cloud PKS
- Vagrant
Hosted solutions(Managed service)
- GKE, AKS, EKS, OpenShift online
223. Configure High Availability
single master -> multiple master node, API Server 앞에 LB(Load Balancer : nginx, HAproxy 등을 둔다)
single master 클러스터에서 master node에 장애가 생기면worker node의 컨테이너는 계속 수행된다.
새로운 node나 pod를 추가할 수 없다. master node에 대한 장애 대비로 마스터 노드를 다수로 구성할 수 있다.
224. ETCD in HA
- default 2379 port 사용
multiple ETCD는 모두 active 모드(read/write 가능)
다른 ETCD에서 write가 발생하면 내부적으로 leader와 follower로 구분하여 follower 로 write로 요청이 오면,
leader로 write을 보낸다. leader는 follower에 데이터를 동기화한다.
leader election - RAFT
섹션11: Install a kubernetes cluster with kubeadm
master, worker1, worker2
1. docker 전체 설치
2. kubeadm 전체 설치
3. initialize(master node only)
4. CNI(master node only) : POS Network
5. join(worker node)
| master node | worker node1 | worker node2 | |
| docker 설치 | ✔ | ✔ | ✔ |
| kubeadm 설치 (kubelet, kubectl 포함) |
✔ | ✔ | ✔ |
| master initialize | ✔ | ||
| POD network(CNI) | ✔ | ||
| join | ✔ | ✔ |
- vagrant 로 설치
- kubeadm 으로 설치
섹션12: end to end test on a kubernetes cluster
As per the CKA exam changes (effective September 2020), End to End tests is no longer part of the exam and hence it has been removed from the course.
If you are still interested to learn this, please check out the complete tutorial and demos in our YouTube playlist:
https://www.youtube.com/watch?v=-ovJrIIED88&list=PL2We04F3Y_41jYdadX55fdJplDvgNGENo&index=18
섹션13: trouble shooting
235. Application Failure
user - WEB-service - WEB - DB-service - DB
checking
check WEB-service
curl http://IP:port check
kubectl describe service web-service
check POD
kubectl get pod
kubectl describe pod
kubectl get events
kubectl logs web -f --previous
check DB-service
check DB
238. Control Plane Failure
service kube-apiserver status
service kube-controller-manager status
service kube-scheduler status
service kubelet status
service kube-proxy status
check service logs
- kubectl logs kube-apiserver -n kube-system
241. Worker Node Failure
246. Pre-Requisites - JSON PATH
Use the code - DEVOPS15 - while registering for the CKA or CKAD exams at Linux Foundation to get a 15% discount.
DEVOPS15
'쿠버네티스' 카테고리의 다른 글
| CKA 자격증 취득하기 - 시험예상 문제 (0) | 2022.06.09 |
|---|---|
| 쿠버네티스 보충 (0) | 2022.06.08 |
| CKA 자격증 취득하기 #1 (0) | 2022.05.18 |
| 쿠버네티스 - secret (0) | 2022.05.18 |
| 쿠버네티스 - configmap (0) | 2022.05.18 |