개요 고객사에서 coreDNS 쪽 질의가 안 된다는 요청을 받다보니 알게 된 정보들을 정리합니다..! 파드에서 FQDN 요청 시, coreDNS는 어떻게 동작할까? 파드 내에서 {도메인}으로 질의를 하게 되면 파드 내의 /etc/resolv.conf의 search 리스트를 붙여가며 coreDNS에 질의를 하게 됩니다. 질의 순서 {도메인}.ingress-nginx-system.svc.cluster.local {도메인}.svc.cluster.local {도메인}.cluster.local {도메인}.tail3cceb.ts.net ![](https://velog.velcdn.com/images/numerok/post/cd095b84-46f3-4355-a8f2-72c87b23f5f0/

개요 업무 중, 다음과 같은 질문을 받았습니다.. "현재 파드의 자원할당 설정 내용을 보면 리미트값과 리퀘스트 값이 존재하는데 8이라는 cpu값을 주고 싶고, 7이라는 cpu 값에 도달했을 때 파드의 재기동을 자동으로 유발시키려면 설정을 아래와 같이 하면 될까요?" 질문에서 시작된 requests, limits에 대해 알아보기..❗ resources 필드 아래는 explain으로 확인한 resources 필드입니다. 컨테이너에서 필요한 리소스를 정의하는 필드로 하위 필드로는 limits, requests가 있습니다. 지정할 수 있는 리소스는 CPU, Memory가 일반적이며 다른 리소스(hugepages-*)들도 있습니다. 리소스 단위 CPU CPU 단위는 코어로 정의 됩니다. 예시 1 = 1코어 0.5 = 0.5코어 500m = 0.5코어 쿠버네티스에서 CPU 리소스를 1m보다 더 정밀한 단위로 표기할 수 없습니다. 때문

https://metallb.universe.tf/concepts/layer2/ metalLB 공식 문서를 읽고 정리한 내용입니다. Metal...LB..? layer 2모드에서는 서비스 IP에 대한 모드는 트래픽이 하나에 노드로 가게 된다. 그 후, kube-proxy에 의해 트래픽들이 서비스 파드로 분산되게 된다. 따라서 layer 2모드에서는 load balaner이라고 보기는 어렵지만, failover 기능이 구현되어 있기 때문에 리더인 노드에 특정한 이유로 장애가 날지라도 다른 노드로 자동으로 리더 역할이 넘어가게 된다. memberlist에 의해 장애노드가 감지 되고, 새로운 노드는 장애 노드로부터 IP를 가져오게 된다. layer 2 mode의 한계 layer 2 모드에서는 2가지의 주요한 한계가 있습니다. single-node bottlenecking potentially slow failover 위에서 언급했듯이 layer 2 모드의 단일 리

개요 master 다중화가 되어 있는 kubernetes cluster의 etcd cluster save 및 restore 방법 사전요구사항 etcd pod에 직접 exec하여 실행할 수 있지만, kubectl cp가 불가능 한 경우 snapshot 파일을 사용할 수 없습니다. 따라서 etcdctl binary 파일이 필요합니다. etcdctl 설치방법 etcdctl 설정 etcdctl은 etcd 인증서를 참조하여 etcd와 통신하여 명령어를 실행합니다. 실행할 때마다 작성하면 번거로우니 alias로 등록해줍시다. 백업 및 복구 snapshot 저장 snapshot 상태확인 snapshot 복구 마스터노드에서 각각 진행합니다. 참고문서 etcdctl 설치 [https://etcd.io/docs/v3.4/op-guide/recov

에러상황 파이프라인을 실행하는 과정에서 podman-build 태스크가 실행조차 되지 않아 확인한 결과,more than one PersistentVolumeClaim is bound 라는 메시지를 표시하고 있었습니다. 원인 파이프라인 구조 태스크 코드 git-clone podman-build workspace 정의 두 개 이상의 workspace에서 하나의 pvc를 사용하려고 해서 생기는 문제입니다. git-clone 태스크에서 이미 s2i workspace ( cicd-pvc )를 사용했는데, podman-build 태스크에서 또 다시 s2i workspace ( cicd-pvc )를 사용하려고 하여 에러가 난 상황입니다. 해결방법

개요 kubelet의 저장 가능한 로그 파일의 크기는 default로 10Mi로 설정되어 있어, 10Mi가 넘는 로그는 전체 로그를 확인할 수 없습니다. 설정 변경 vi /etc/kubernetes/kubelet-config.yaml 을 실행합니다. ContainerLogMaxSize 필드를 원하는 용량으로 변경합니다. systemctl restart kubelet kubelet 서비스를 재기동합니다.

개요 점검 시, Running 상태가 아닌 파드 들은 기본적으로 describe를 확인하여 Event 확인이 필요합니다. 1, 2개일 경우 수작업으로 확인이 쉽지만, pod나 node가 많은 경우 어려움이 있어 pod는 running, completed 상태가 아니면, node는 Ready 상태가 아니면 describe 한 결과를 파일로 저장하도록 shell scripts 를 작성하였습니다.

0. 개요 kubernetes 클러스터를 최초 설치 시, 생성되는 인증서의 기한은 1년입니다. 이 인증서 기간이 만료되면 kubernetes 클러스터를 사용할 수 없어, 인증서를 주기적으로 갱신해야 합니다. 0.1. 환경 Master Node 3대, Worker Node 2대 k8s 버전 1.19.4 1. 작업 전 백업 etcd 백업 >버전에 따라 인증서의 경로가 ssl이 아닌 pki인 경우가 있습니다. 인증서 백업 엔지니어라면 항상 백업은 필수 ❗❗ > 각 Master Node의 인증서는 다르기 때문에, 모든 Master Node에서 각각 백업하여야 합니다. 2. 인증서 갱신 kubernetes version <= 1.19 이후 kubernetes verion 인증서 날짜 갱신 확인 static pod 재기동 kube-scheduler, kube-apiserver, kube-controller-manager

0. 개요 0.1. 환경 0.1.1. OS 버전 CentOS Linux 7.9 OS는 rpm 파일 다운 시 영향이 있습니다. 0.1.2. cluster 환경 maseter/woker 1대, worker 2대로 구성되어 있습니다. CONTAINER-RUNTIME은 cri-o를 사용합니다. 0.2. 작업 목표 kubernetes 1.19.x를 1.21.x로 업그레이드 하기 0.3. 필요한 내용 백업 vi /etc/kubernetes/manifests/kube-apiserver.yaml가 초기화 되기 때문에 설정 1. Setting 1.1. kubernetes repo 추가 kubernetes 1.20.1과 1.21.14 패키지를 받기 위한 repo를 추가합니다. 자세한 내용은 [install-kubectl-linux](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#in

명령어로 조회 시, EXTERNAL-IP에 IP가 할당 되어야 하지만 Pending 상태인 서비스가 있었습니다. metallb-controller 파드의 로그는 다음과 같습니다. 확인 결과 data.config.address-pools.addresses 스펙에서 192.168......-192.168.... 처럼 대역으로 사용하면 문제가 없지만 - 192.168..... 와 같이 한개의 ip만 지정한다면 prefix (/32) 를 지정해주어야합니다.

파드가 Terminating 상태가 되었음. 노드 조회 해보니 노드 NotReady상태 해당 노드 VM이 꺼져 있었음 --> os 가 꺼지고 VM이 꺼져야하는데, VM을 바로 꺼버려서 문제가 생김 VM 재기동 하고 kubelet, crio 재기동 파드가 사라지고 컨테이너도 사라짐 deploy 0/1이고 rs는 생성되어 있는 상태 deploy replicas 0으로 내리고 rs 삭제 후, replicas 1로 다시 올리면 정상화 6-7 과정 실패 시, mutator 이슈 확인 필요

Error 상황 Error 원인 calico-node가 nic가 두 개일 때 어떤 인터페이스를 찾아가야 할 지 몰라서 생기는 에러 제 환경 같은 경우에서는 ens192 인터페이스의 ip로 지정되어야 하는데 10번대 ip를 가진 cni0 인터페이스로 calico-node가 선택을 해 192번대 ip와 BGP가 불가능하였다. 해결 방법 calico version이 3.13.* 버전이라 cidr 을 통한 ~ 는 불가능하여 cni 인터페이스를 참조하지 않도록 calico-node의 daemonset env 를 수정하여서 해결하였습니다. Excluding matching interfaces 아래의 Including matching interfaces와 같이 인터페이스명을 직접 지정하는 방법도 가능하지만 한 노드에서 master1와 인터페이스 이름이 다르고 ens로 시작하는 인터페이스가 두 개라 \*과 같은 정규식으로 인터페이스

상황 calico.yaml을 통해 calico를 배포하는 과정에서 calico pod가 해당 에러를 출력하며 pod 상태가 ContainerCreating 상태로 유지되는 상황 환경 |패키지|버전| |---|---| |CentOS|7.7 |cri-o|1.17.4 -> 1.19.2 원인 cri-o version 1.17.4에서 cri-o 1.19.2로 재설치 하였으나 외부 연결이 되지 않은 폐쇄망 환경이기 때문에 의존성 패키지들이 업데이트 되지 않아 생긴에러 해결 방법 1.19.2에 맞는 containerd 버전을 새로 설치하니, 정상적으로 pod 작동 절차 cri-o 버전에 맞는 containerd rpm 파일 다운로드 합니다. https://download.docker.com/linux/centos/7/x86_64/stable/Packages/ rpm 파일을 이용하여 containerd를 새 버전으로 설치합니다. 패키지 업그레이드

kubeadm init 으로 클러스터 생성 시, join에 필요한 token, hash와 함께 join 커맨드가 나오지만, 이 token은 유효기간이 24시간이고, 값을 따로 복사해두지 않으면 join을 할 수 없게 됩니다. 작업 Step 1. kubernetes api-server의 token, hash 확인 클러스터의 main master node로 접속합니다. 클러스터의 토큰을 확인합니다. 토큰이 없다면 토큰을 생성합니다. hash 값을 조회합니다. Step 2. node를 클러스터에 join하여 추가 join할 node로 접속합니다. 조회한 token값과 hash 값을 사용하여 join 합니다. master node로 돌아가 node가 추가 되었는지 확인합니다. > 토큰 생성 시, --print-join-command 옵션을 사용하면 Step 1의 과정을 생략하고 바로 join 커맨드를 확인

목적 애플리케이션이 파드로 실행인 클러스터에서 master node / woker node를 제거 하기 위함 환경 해당 문서에서 사용된 컨테이너 런타임은 cri-o입니다. |패키지|버전| |---|---| |cri-o|1.17.4| |kubernetes|v1.17.6| 작업 Step 1. 제거할 node를 스케줄 불가로 표시 node 목록을 조회하여 제거할 node를 확인합니다. cordon을 실행하여 node를 스케줄 불가로 표시합니다. 노드를 스케줄 불가로 표시하면 스케줄러가 해당 노드에 새 파드를 배치할 수 없지만, 노드에 있는 기존 파드에는 영향을 미치지 않습니다. node 목록을 조회하여 제거할 node가 SchedulingDisabled 상태인지 확인합니다. Step 2. drain 하여 pod를 유지할 node로 이동 Node에 PDB가 있는지 확인합니다. PDB가 있다면, PDB 데이터를 백업

Control plane을 여러개로 하는 이유 Kubernetes에서 Control plane(이하 CP)은 노드들을 관리합니다. 시스템에 장애가 생기면 아무것도 관리 할 수 없기 때문에 Sigle Point of Failure 문제가 발생할 수 있게 됩니다. 따라서 고가용성을 위해 CP를 여러 개 두는데 이 때 짝수개로 생성하면 문제가 발생할 수 있습니다. Control plane을 홀수개로 구성하는 이유 Control plane에는 etcd라는 스토리지가 있습니다. 멀티 클러스터링을 하게 되면 etcd는 분산 클러스터가 됩니다. 이때 etcd는 RAFT 합의 알고리즘을 통해 데이터의 일관성을 유지하게 됩니다. RAFT 합의 알고리즘이란 요청을 수행할 때 Yes/No로 투표를 하게 되고, 과반수 이상의 노드가 있는 쪽의 요청을 유효한 요청으로 수행하게 되는 알고리즘입니다. etcd는 RAFT 알고리즘을 통해 어떤 클러스터가 primary인지 결정하게 됩니다.![](https

TLS/SSL Termination with Ingress SSL 더이상 사용하지 않음 TLS만 사용 상징적인 의미로 SSL 용어를 사용 end to end 암호화 client LB Server TLS Termination 프라이빗 네트워크가 있고 그 안에 암호화를 제공하지 않는 평문 통신구간이 있음 end to end 방식보다 선호 됨 장점 프록시와 서버간의 암복호화를 하지 않아서 서버에 암복호화 부담이 적음 인증서를 서버별로 관리하지 않아도 됨 보안장비를 프록시에만 설정할 수 있음 위

동적 프로비저닝 PVC만들면 바운딩될 PV를 자동으로 만듬 PV가 실제로 연결 어떤 근거로? 템플릿이 있음 -> 스토리지 클래스 SC 관리자가 SC만들어둠 사용자는 PVC를 만들 때 스토리지 클래스를 지정 https://rook.io/ 쿠버네티스를 위한 스토리지 제공 ROOK 오픈소스 사전요구사항이 있음 실제 스토리지 구현이라 사용할 디스크가 있어야함 Vagrantfile >up 하기전에 vagrant snapshot save before-rook 스냅샷 만들기 스냅샷 복구 vagrant restore save before-rook ceph 별도의 오픈소스 https://ceph.io/en/ 파일, 블록, 오브젝트 스토리지 제공 by ceph -> Intergrated storage 통합 스토리지 rook-ceph 구성 https://rook.io/docs/rook/latest/Getting-Started/quickstart/ 오픈소스 코드

Ingress L7 LB = ALB 인그레스 컨트롤러 인그레스를 구현하기 위한 컨트롤러 ing.spec ing.spec.rules ing.spec.rules.http hostname을 포함하는 www.naver.com 도메인 www호스트 naver.com 도메인 와일드 카드도 가능 *foo.bar.com 앞에 뭐가 붙던 괜찮음 도메인은 실제로 존재해야함 ing.spec.rules.http.paths ing.spec.rules.http.paths.backend ing.spec.rules.http.paths.backend.resource

데몬셋 stop을 하거나 시스템을 끄기전까지 계속해서 실행하는 앱 -> 이걸 제어하는게 서비스데몬 노드마다 하나씩 파드 배치 -> 데몬셋은 모든(일부) 노드 파드의 사본을 실행 -> 템플릿 실행 데몬셋은 DS -> 복제본이라는 개념은 없음 반드시 하나의 노드에 하나씩 무조건적으로 하나씩 있음 -> 분산을 보장 노드에서 작업을 해야하는 앱들에서 사용 EX) 스토리지 어플리케이션 워커노드에 스토리지(디스크) 파드에게 제공하기 위해서 그냥 제공 가능? --> 그건 아님 kubernetes가 연결할 수 있는 컨테이너 스토리지 인터페이스라는게 있음 CRI CNI CSI 인터페이스를 통해 접근해야함 -> Rook ceph 사용 이런애들을 관리하기 위해선 데몬이 필요함(스토리지를 관리할) RS와의 차이 ![](https://velog.velcdn.c