본문 바로가기

전체 글167

Section 6 : Cluster Maintenance 1. Operating System Upgrade  만약 여러개의 노드 중 하나가 다운됐다면, 쿠버네티스는 어떤 행동을 할까요?1. 노드가 즉시 다시 시작된다면, kubelet process가 시작되고, pod가 다시 online으로 돌아옵니다.2. 만약 node 다운이 5분 되었다면, 해당 노드에서 pod가 종료됩니다. 쿠버네티스가 죽은 것으로 여기고, pod가 replicaSet으로 생성되었다면, 다른 노드에 다시 생성할 것입니다.   pod-eviction-timeout이라고 알려진 controller manager에 놓여진 것은, 기본적으로 5분이라는 디폴트 값을 설정해 놓습니다.다시 말해 노드가 오프라인이 될 때마다 마스터 노드는 최대 5분까지 기다립니다. 만약 pod-eviction-timeo.. 2024. 7. 2.
KodeKloud - Test Record (section 5) 1. Rolling Update, Recreate [ 1 ] deployment .yaml 파일을 바꿀 때 set과 edit을 사용할 수 있다. 2. Commands [ 1 ] Create a pod with the given specifications. By default it displays a blue background. Set the given command line arguments to change it to green. > kubectl run webapp-green --image=kodekloud/webapp-color --dry-run=client -o yaml > kubectl run webapp-green --image kodekloud/webapp-color -- --color g.. 2024. 3. 11.
Section 5 : Application Lifecycle Management 1. Rollout and Versioning : 처음 배포를 생성하면 새로운 Rollout은 새로운 revision을 생성합니다. 컨테이너 버전이 새것으로 업데이트 되면 새 Rollout이 트리거되고, 새로운 배포 revision을 생성합니다. 배포에 일어난 변화를 추적하고, 전버전으로 돌아갈 수 있게 돕습니다. 배포 전략에는 2가지가 있습니다. 1) 기존의 것을 삭제하고, 새로운 것을 배포하는 방법은 구 버전이 다운되고, 새로운 버전이 업데이트 되기 전 기간에 응용 프로그램이 다운되어 사용자가 사용이 불가합니다. 이 Recreate 전략은 기본적으로 잘 사용되지 않습니다. 2) 한꺼번에 전부 삭제하지 않고, 하나씩 삭제하며 새 버전을 올리는 방법이 있습니다. 이는 응용 프로그램이 다운되지 않고, 업.. 2024. 3. 10.
5. 질문 (웹 브라우저에 URL 전체 동작과정) [가정] PC : window NAT : 공유기 브라우저에 URL 입력하면 -> 운영체제에 따라 다름(window라고 가정) -> 만약 www.naver.com 검색을 한다면, naver.com의 IP를 알아야 함 -> : 이때 DNS에 질의를 하게 되면 IP를 획득하지만, 항상 DNS에 물어보지는 않음. (1) 컴퓨터가 가지고 있는 hosts 파일을 확인 (2) 그전에 DNS 질의했다면, 컴퓨터가 이 응답을 캐싱합니다. 그래서 캐시 결과를 보고 DNS에게 물어볼 필요가 없다면 질의X (3) 위에도 없다면 DNS에 질의를 하는데, 여기서 다시 나뉨. [ 1 ] 만약 공유기를 사용하고, 컴퓨터의 DNS 설정이 공유기로 되어있다면 공유기가 DNS에 질의 후 응답을 받아 컴퓨터에 넘길 수 있음. [ 2 ] 만.. 2024. 3. 9.
KodeKloud - Test Record (section 3 & 4) 1. Manual Scheduling [ 1 ] (Pod의 삭제와 생성을 동시에) > kubectl replace --force -f nginx.yaml 2. Label & Selector [ 1 ] We have deployed a number of PODs. They are labelled with tier, env and bu. How many PODs exist in the dev environment (env)? Use selectors to filter the output > kubectl get pods --selector env=dev | wc -l > kubectl get all --selector env=prod (wc - l 을 추가하면 해당 개수를 나타내 줄 수 있음, 헤더 포함 /.. 2024. 2. 22.
Section 4 : Scheduling & Logging, Monitoring 1. Manual Scheduling : 만약 클러스터에 스케줄러가 없을 때는 어떻게 할까요? 이때는 직접 Pod를 스케줄링 할 수 있습니다. 먼저 기본 스케줄링부터 알아보죠. Pod의 yaml 파일에는 nodeName 이라는 설정이 가능합니다. 스케줄러는 모든 Pod를 보고 이 속성이 없는 것을 찾습니다. 스케줄링 알고리즘을 실행해 Pod의 올바른 노드를 식별해서 지정합니다. 스케줄러가 없을땐 직접 설정해주면 됩니다. Pod의 yaml에 nodeName 속성에다가 노드의 이름을 작성해주면 되는 것이지요. 노드 이름은 생성할 때만 지정할 수 있습니다. 이미 노드에 속해있는 Pod는 노드를 변경할 수 없으며, 이를 가능하게 하는 방법은 바인딩 개체를 생성하고, Pod의 바인딩 API에 요청하는 것 입니다... 2024. 2. 22.
Section 3 : Core Concepts k8s Controllers는 k8s에 숨은 두뇌입니다. k8s 객체 모니터링을 진행하고, 이에 반응합니다.Replication Controller: k8s 클러스터에 있는 단일 Pod의 다중 인스턴스를 실행하도록 도와 고가용성을 제공합니다. 항상 Pod가 실행되도록 보장합니다. 개수에 상관없이. 서로 다른 노드의 여러 Pod에 걸쳐 부하를 분산하는 데 도움이 되고, 수요가 증가하면 앱 스케일도 조정할 수 있습니다. (Replication Controller vs ReplicaSet 서로 비슷하지만 다르고, controller는 구식이다)   이에 대한 yaml 파일도 apiVersion, kind, metadata, spec으로 구성되어 있습니다. Replication Controller yaml 파일.. 2024. 2. 15.
KodeKloud - Test Record (section 2) 1. Pods [ 1 ] Which nodes are these pods placed on? > kubectl get pods -o wide [ 해당 옵션으로 어떤 Node에 선정되었는지 볼 수 있었음 ] [ 2 ] Create a new pod with the name redis and the image redis123. Use a pod - definition YAML file. And yes the image name is wrong! > kubectl run redis —image=redis123 —dry-run=client -o yaml > redis.yaml [ Print the result (in YAML format) of updated nginx deployment with the ser.. 2024. 2. 14.
Section 2 : ETCD & Components ETCD ETCD : 분산, 속도, 신뢰할 수 있으며 고가용성을 제공하는 분산 키-값 저장소입니다. 키값 저장소 : 정보를 문서나 페이지 형태로 보관합니다. 각 문서를 받고, 그 개인 데이터에 대한 모든 정보는 해당 파일에 저장됩니다. Etcd 컨트롤 클라이언트는 etcd의 커맨드라인 클라이언트 입니다. 키값 쌍을 저장하고 회수할 수 있습니다. etcd에서 사용되는 Raft 합의 알고리즘은 분산 시스템에서 일관성과 안정성을 보장하기 위해 설계된 분산 일관성 알고리즘입니다. Raft 알고리즘은 리더와 팔로워, 후보자 세 가지 역할로 분리되어 있습니다. 각 노드는 이러한 역할 중 하나를 가지며, 시스템이 동작하는 동안 상태를 전환할 수 있습니다. etcdctl은 etcd와 상호 작용하기 위한 CLI 도구입니.. 2024. 2. 12.
Section 1,2 : Introduction & Cluster Architecture & Docker vs ContainerD 1. Introduction 객관식이 아니기 때문에 기술이 어떻게 작동하고, 작동하는지 알아야 한다. 공식 문서를 잘 찾는 방법이 중요합니다. 최신 시험은 2시간이 주어지고, 참고자료는 아래와 같습니다. 인증된 Kubernetes 관리자: https://www.cncf.io/certification/cka/ 시험 커리큘럼(주제): https://github.com/cncf/curriculum 후보자 핸드북: https://www.cncf.io/certification/candidate-handbook 시험 팁: http://training.linuxfoundation.org/go//Important-Tips-CKA-CKAD 노트, 문서 링크, 그리고 실습 문제의 답변들이 있는 저장소를 만들었습니다. 과정.. 2024. 2. 8.
21. Storage - NFS(FileStorage), Longhorn(BlockStorage) & Logging - PLG Stack 1. PV Volume Plugin PV는 기본 속성 중 capacity라는 용량을 설정하는 부분과 accessMode를 지정하는 부분이 있고, Volume Plugin이라고 해서 이 PV의 실질을 결정하는 옵션이 있습니다. 1) hostPath : 이 PV를 hostPath로 만들면 워커 노드에 지정된 /path를 이 PV에 대한 볼륨으로 사용하겠다는 것 입니다. 2) NFS : 웹 스토리지에 NFS 서버가 고정되어 있다면 PV의 Volume Plugin을 NFS로 지정하게 되면 이 PV는 외부에 있는 NFS와 연결할 수 있는 NFS 클라이언트의 역할을 하게 됩니다. OS에 NFS 클라이언트가 설치되어 있어야 합니다. 3) Cloud Service Volume : Azuer, GCP, AWS 등 클라우.. 2024. 1. 30.
20. Networking - Pod / Service Network(Calico), Pause Container 1. 먼저 Master, Worker 노드들이 있고, Pod Network에 대한 영역이 있습니다. 처음 클러스터 설치 시 pod-network-cidr로 이 네트워크 대역에 대한 영역을 설정했던 부분입니다. Pod Network에 대해 알아볼 영역은 Pod내에 컨테이너로 가는 네트워킹을 하는 부분입니다. Pod가 생성되면 Pod Network 범위 내에서 고유 IP를 가지고 있는 인터페이스가 생기는데 이것을 통해서 어떻게 여러 컨테이너들 간에 통신이 되는지 알아보겠습니다. 그리고 또 다른 Pod가 생성되었을 때 이 두 Pod간의 통신은 k8s에서 Node마다 설치가 되는 Network Plugin에 의해 통신이 됩니다. k8s에서 기본적으로 제공하는 큐브넷이라는 네트워크 플러그인이 있는데 이건 네트워크.. 2024. 1. 26.
19. Component : kube - apiserver, etcd, kube - schedule, kube - proxy, kube-controller-manager k8s는 한 대의 Master, Workers 노드들로 구성이 되는데, Master에는 Control plane Component라고 k8s 주요 기능들을 담당하는 컴포넌트들이 있고, Worker Node Component라고 해서 컨테이너를 관리하기 위한 기능들이 있습니다. [ Pod 생성 예제 ] 먼저 Master 노드에는 위와 같이 Etcd, kube-scheduler, kube-apiserver가 있는데 일반적인 설치를 했을 때 이 컴포넌트들은 Pod의 형태로 띄워져서 구동 중인 상태입니다. k8s가 기동시에 /etc/kubernetes/manifests 있는 위 3개의 .yaml 파일을 읽어서 이 Pod들을 static으로 띄웁니다. Worker 노드에는 kubelet, Container Run.. 2024. 1. 26.
18. Autoscaler k8s의 Autoscaler에는 3가지가 있습니다. Pod의 개수를 늘리는 HPA, Pod의 리소스를 증가시키는 VPA, 클러스터에 노드를 추가하는 CA가 있는데 각각의 개념과 동작 방식을 확인해보겠습니다. 1. HPA, VPA, CA 1. HPA (Horizontal Pod Autoscaler) : 컨트롤러가 있고, Replicas 수치에 따라 Pod가 만들어져서 운영이 되고 있는 상태입니다. 서비스도 연결이 돼서 모든 트래픽이 해당 Pod로 흐르는 상황입니다. 트래픽이 많아져서 Pod 내에 있는 리소스를 모두 사용하게 됐고, 조금 더 트래픽이 증가되면 Pod는 죽을 수 있습니다. 만약 사전에 HPA 만들어서 Controller에 연결을 해놓았다면 HPA가 Pod의 리소스 상태를 감지하고 있다가 위험한.. 2024. 1. 22.
17. Ingress 1. Ingress 사용 목적 Ingress 사용 목적으로 대표적인 Service LoadBalancing, Canary Upgrade가 있습니다. Service LoadBalancing은 만약 쇼핑몰을 운영 중이라고 가정했을 때 쇼핑페이지와 고객센터, 주문 서비스를 Pod별로 각각 만듭니다. 이렇게 애플리케이션을 나누면 독립적이기 때문에 하나 장애가 생기더라도 다른 서비스는 영향이 없습니다. 또한 외부에서 연결할 수 있도록 각각 서비스를 달아주고, 사용자들로 하여금 쇼핑페이지에 접근하기 위해서는 www.mall.com 도메인 이름으로 고객센터에 접근하려면 /customer, 주문 서비스로 접근하려면 /order 붙여서 접근하도록 하고 싶을 때 일반적으로는 각각의 Path에 따라 각 서비스 IP를 이어줄.. 2024. 1. 22.
16. StatefulSet 어플리케이션 종류에는 Stateless Application, Stateful Application 있습니다. Stateless 대표적으로 웹 서버입니다. Stateful 대표적으로 데이터베이스입니다. Stateless는 앱이 여러개 배포되더라도 다 똑같은 서비스의 역할을 합니다. Stateful은 각각의 앱마다 자신의 역할이 있습니다. 몽고 DB 경우를 보면 하나는 Primary 역할, 또 하나는 Secondary, 그리고 Arbiter 역할이 있습니다. Primary는 Main DB이고, 이가 죽으면 Arbiter가 이것을 감지해서 Secondary가 대신 역할을 할 수 있도록 변경해줍니다. 1. 단순 복제인 Stateless 앱과 달리 Stateful 앱은 각 앱마다 본인의 고유 역할을 가지고 있습.. 2024. 1. 22.
8. 인덱스 (상) 8.2 인덱스 : 책으로 예를 들었을 때 인덱스는 맨 뒤 찾아보기, 책의 내용은 데이터 파일에 해당한다고 볼 수 있다. 찾아보기를 통해 알 수 있는 페이지 번호는 데이터 파일에 저장된 레코드의 주소에 비유될 수 있다. 칼럼의 값과 해당 레코드가 저정된 주소를 키와 값의 쌍으로 삼아 인덱스를 만들어 두는 것이다. DBMS의 인덱스는 SortedList와 마찬가지로 저장되는 칼럼의 값을 이용해 항상 정렬된 상태를 유지한다. 데이터 파일은 ArrayList 같이 저장된 순서대로 별도의 정렬없이 그대로 저장한다. 결론적으로 DBMS에서 인덱스는 데이터의 저장 성능(INSERT, UPDATE, DELETE) 희생하고, 대신 데이터의 읽기 속도를 높이는 기능이다. 1. 인덱스를 역할별로 구분한다면 프라이머리 키, .. 2024. 1. 21.
15. Authentication - X506 Certs, kubectl, Service Account / Authorization - RBAC, Role, RoleBinding Authentication 1. X506 Client Certs 먼저 클러스터에 6443 포트로 API 서버가 열려있습니다. 사용자가 https로 접근하려면 k8s 설치시 kubeconfig 라고 해서 이 클러스터에 접근할 수 있는 정보들이 들어있는 파일이 있는데 위처럼 인증서 내용이 있습니다. 여기서 Client Key, crt 복사해서 가져오면 됩니다. 최초에 발급 기간과 클라이언트에 대한 개인 키를 만들고, 이 개인 키를 가지고 인증서를 만들기 위한 각각의 인증 요청서라는 csr 파일을 만듭니다. 이 CA 경우 인증 요청서를 가지고 바로 인증서를 만드는데 kubeconfig에 있는 CA crt 가 이것입니다. 클라이언트 인증서의 경우 발급기간 개인키와 인증서 그리고 클라이언트 요청서를 모두 합쳐서 .. 2024. 1. 17.
14. Volume - Dynamic Provisioning, StorageClass, Status, ReclaimPolicy / Accessing API - Overview 1. Dynamic Provisioning Volume은 데이터를 안정적으로 유지하기 위해 사용합니다. 실제 데이터는 k8s 클러스터와 분리돼서 관리됩니다. 이런 방식으로 관리할 수 있는 종류가 많은데 크게 내부망에서 관리하는 경우 외부망에서 관리하는 경우로 나눌 수 있습니다. 외부망으로는 aws, gcp, microsoft Azure 같은 cloud storage를 두고 여기에 본인의 k8s와 연결해서 사용할 수 있습니다. 내부망에는 이 k8s를 구성하는 노드들이 있는데, k8s에는 노드들의 실제 물리적인 공간에 데이터를 만들 수 있는 hostPath, local Volume이 있고, 별도의 On-premise solution들을 이 노드들에 설치할 수 있습니다. 이 솔루션들이 알아서 노드의 자원을 이.. 2024. 1. 17.
13. Basic Object - Service 사용자의 접근 경우 Service가 만들어진 후에 IP를 확인하고, 이 IP로 접근을 하면 되는데(10.111.41.1) Pod의 경우 이 자원들이 동시에 배포가 될 수 있습니다. Pod A가 Pod B에 접근을 해야하는 상황인데 Pod A에 IP를 넣기에는 Pod나 Service가 동적으로 할당되기 때문에 미리 알기에는 제약이 있습니다. Pod B의 경우 문제가 생겨 죽으면 자동으로 재생성되면서 IP가 변경되기 때문에 Pod A가 IP를 알더라도 계속 쓸 수 없습니다. 이런 문제를 해결하기 위해 DNS, Headless 서비스가 필요합니다. Pod가 외부 특정 사이트에 접근해서 데이터를 가져오는 상황에서 접근 주소를 변경해야 되는 상황이 생기면 경로를 변경해주기 위해 Pod를 수정하고 재배포해야 될까요.. 2024. 1. 16.
7. 데이터 암호화 Mysql 5.7 이후 암호화 기능은 처음에 데이터 파일에 대해서만 암호화 기능이 제공됐다. 8.0 버전부터는 추가로 리두 로그, 언두 로그, 복제를 위한 바이너리 로그 등 모두 암호화 기능을 지원하기 시작했다. 7.1 Mysql 서버의 데이터 암호화 Mysql 서버 암호화 기능은 데이터베이스 서버와 디스크 사이의 데이터 읽고 쓰기 지점에서 암호화 또는 복호화를 수행한다. 별도의 Mysql 서버에서 디스크 입출력 이외의 부분에서는 암호화 처리가 전혀 필요 없다. 즉 Mysql 서버의 I/O 레이어에서만 데이터의 암호화 및 복호화 과정이 실행되는 것이다. MySQL 서버에서는 사용자의 쿼리를 처리하는 과정에서 테이블의 데이터가 암호화 되어있는지 확인할 필요가없다. 왜냐하면, 스토리지에서 데이터를 쓰기전에 .. 2024. 1. 14.
6. 데이터 압축 Mysql 서버에서 디스크에 저장된 데이터 파일의 크기는 일반적으로 쿼리의 처리 성능과도 직결되지만 백업 및 복구 시간과도 밀접하게 연관된다. 디스크의 데이터 파일은 클수록 쿼리를 처리하기 위해서 더 많은 데이터 페이지를 InnoDB 버퍼 풀로 읽어야 할 수도 있고, 새로운 페이지가 버퍼 풀로 적재되기 때문에 그만큼 더티 페이지가 더 자주 디스크로 기록돼야 한다. 그리고 데이터 파일이 크면 백업 시간이 오래걸리며, 복구 하는데 시간이 오래 걸린다. 이런 문제를 해결하기 위해 데이터 압축 기능을 제공한다. 크게 테이블 압축, 페이지 압축 2가지로 구분할 수 있다. 1. 페이지 압축 : "Transparent Page Compression" 이라고도 불리며, Mysql 서버가 디스크에 저장하는 시점에 데이터.. 2024. 1. 13.
12. QoS classes (Guaranteed, Burstable, BestEffort) & Node Scheduling QoS class 위 Qos는 노드에 이렇게 리소스가 있다고 가정하고, 이 노드 위에 Pod가 3개 만들어져서 자원을 모두 사용하고 있는 상태라고 가정합니다. 이 상태에서 Pod1이 추가적으로 자원이 필요할 때 노드에는 추가적으로 할당받을 수 있는 자원이 없기 때문에, 선택을 해야합니다. k8s는 앱의 중요도에 따라 이런 것을 관리할 수 있도록 3가지 단계로 Quality of Service를 지원해주고 있습니다. 현재 위 상태에서는 1. Best Effort가 부여된 Pod가 가장 먼저 다운이 돼서 자원이 반환됩니다. Pod1은 필요한 자원을 추가로 얻게 됩니다. 다음엔 어느 정도 노드에 자원이 남아있지만, Pod2에서 그보다 많은 자원을 요구하는 상황이 됐다면, 2. Burstable이 적용된 Pod.. 2024. 1. 12.
11. Pod - Lifecycle & (ReadinessProbe, LivenessProbe) Lifecycle Pod는 해당 라이프사이클 단계에 따라 주요 행동들이 있습니다. status 안에 Phase라고 해서 Pod의 전체 상태를 대표하는 속성이 있습니다. 그리고 Pod가 생성되면서 실행하는 단계들이 있는데 그 단계와 상태를 알려주는 것이 Conditions라는 특성입니다. 또한 컨테이너마다도 State라고 해서 각각의 컨테이너를 대표하는 상태가 있습니다. 먼저 Pod를 대표하는 Phase 종류는 아래와 같습니다. (1) Pending, (2) Running (3) Succeeded, (4) Failed, (5) Unknown Conditions는 4종류가 있고, Reason이라고 해서 Condition의 세부 내용을 알려주는 항목이 있습니다. (1) Initizlized, (2) Conta.. 2024. 1. 12.
RealMysql8.0 (CKA 공부에 전념하기 위해 잠시 멈췄습니다.) 1주차 - https://github.com/himJJong/-Mysql8.0-study/issues/1 2주차 - https://github.com/himJJong/-Mysql8.0-study/issues/2 3주차 - https://github.com/himJJong/-Mysql8.0-study/issues/3 2024. 1. 11.
10. Controller - DaemonSet, Job, CronJob 노드들이 있고, 각각의 노드에 자원이 다르게 남아있는 상태에서 이전에 배운 ReplicaSet의 경우 Pod를 스케줄러에 의존해서 노드에 배치를 할 때 만약 노드1에 자원이 많이 남아 있는 상태면 위처럼 배치를 많이 할거고, 자원이 별로 없다면 Pod를 배치 안할 수 있습니다. DaemonSet : 노드의 자원 상태와 상관없이 모든 노드에 Pod가 하나씩 생긴다는 특징이 있습니다. 이렇게 사용되는 서비스로 대표적인 1. 성능 수집인데 각 노드들의 성능상태는 모두 감시 대상이죠. 그래서 모니터링 화면이 있을거고, 각각의 노드에 프로메테우스 같은 수집 에이전트가 깔여 있어야 모든 노드들의 정보들을 모니터링 시스템에 전달해 줄 수가 있습니다. 2. 로그 수집인데, 특정 노드에 문제가 파악했다면 로그를 확인해야.. 2024. 1. 10.
9. Controller - Deployment & 실습 Deployment는 현재 한 서비스가 운영 중인데 이 서비스를 업데이트 해야 돼서 재배포를 해야 할 때 도움 주는 컨트롤러 입니다. 크게 아래와 같이 4가지 방식이 있습니다. ReCreate : Deployment를 만들면 이렇게 v1의 파드가 생성됩니다. 그리고 Pod 하나당 위와 같이 하나씩 자원이 사용된다고 가정하겠습니다. Deployment는 먼저 Pod 모두 삭제합니다. 그렇게 되면 서비스에 대한 다운타임이 발생하고, 자원 사용량도 없어지게 됩니다. 그 후 v2에 대한 Pod 2개를 만들어 줍니다. 단점은 다운타임이 발생해서 일시적인 정지가 가능한 서비스인 경우에만 가능한 방법입니다. Rolling Update : 원래의 상태에서 업그레이드 할 때 Deployment는 먼저 v2의 Pod를 하.. 2024. 1. 10.

티스토리툴바