샤인의 IT (막 적는) 메모장

네임스페이스 리소스 관리를 위한 ResourceQuota와 LimitRange에 대해 알아본다. ResourceQuota는 네임스페이스, LimitRange는 각 컨테이너에 대한 자원을 제한한다. ResourceQuota #ResourceQuota 오브젝트 apiVersion: v1 kind: ResourceQuota metadata: name: mem-cpu-demo spec: hard: requests.cpu: "1" #Request 정보 requests.memory: 1Gi limits.cpu: "2" # Limit 정보 limits.memory: 2Gi pods: "2" # 파드 수 제한 #리소스 쿼타 생성하고 해당 resourceQuota 리소스의 status를 확인하면 현재 사용 중인 정보를 ..

cgroupfs 말고 systemd Kubernetes에서는 cgroupfs 말고 systemd 드라이버 사용을 권장한다. 왜냐하면 kubelet이 daemon으로 올라가기 때문이다. systemd로 설정하기 위해 다음과 같은 작업을 수행하여야 한다. #kubeadm 설정 vi /etc/kubernetes/kubeadm-config.yaml ... kind: KubeletConfiguration apiVersion: kubelet.config.k8s.io/v1beta1 cgroupDriver: systemd ... #kubelet 설정 kubectl get cm -n kube-system | grep kubelet-config kubectl edit cm kubelet-config -n kube-syst..

Label Label은 Object에 첨부된 키와 값의 쌍이다. Object의 특성을 식별하는 사용하지만 시스템에 직접적인 의미는 없다. 유효한 Label값 63자 이하, 시작과 끝은 영숫자, '-', '_', '.' 사용 가능 ... metadata: name: my-pod labels: app: my-app spec: ... Annotation Annotation은 임의의 비-식별 메타데이터를 오브젝트에 첨부할 수 있다. 키와 값은 문자열이어야 하며 각각 기록할 수 있는 정보들은 다르게 사용할 수 있다. 예를 들어 빌드 정보, 릴리스 날짜, 타임스탬프, Git 정보, 디버깅 정보 등등.. 개발자가 추가할 수 도 있고 다른 오픈소스에서도 해당 어노테이션을 통하여 설정정보를 입력하기도 한다. (Annot..

Namespace는 클러스터 내에서 리소스 그룹을 격리하는 환경을 제공한다. 동일한 네임스페이스 내에서 리소스를 구별하기 위해서 Label을 사용함. 초기 클러스터 구성 시 생성되는 네임스페이스는 4가지 default - 다른 네임스페이스가 없는 오베직트를 위한 기본 네임스페이스 kube-system - 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스 kube-public - 모든 사용자가 읽기 권한으로 접근, 클러스터 중 읽을 수 있는 리소스를 위해 예약되어 있음 kube-node-lease - scale될 때 노드 하트비트의 성능을 향상시키는 노드와 관련된 lease 오브젝트 네임스페이스는 서비스를 생성할 때 DNS 엔트리가 생성된다. ..svc.cluster.local # Namespace..

오브젝트란 K8s 시스템에서 영속성(Persistent)를 가지는 오브젝트 K8s에서 클러스터 상태를 나타내기 위하여 오브젝트를 사용한다. 오브젝트를 통해 클러스터 상태를 나타내기 위하여 구체적으로 말하면 다음과 같음. 1. 어떤 컨테이너화 된 App이 동작 중인가? 2. 컨테이너화 된 App이 사용하는 리소스는 무엇인가? 3. 컨테이너화 된 App이 재구동 정책, 업그레이드, 내고장성 같은 것들을 어떻게 동작해야 하는가? 오브젝트를 생성, 수정, 삭제 등 이용하기 위해서 K8s API를 이용해야 함. 오브젝트는 크게 spec 과 status로 나눌 수 있는데 spec은 리소스의 원하는 특징에 대해서 설정하는 필드 status는 K8s 시스템 컴포넌트에 의해 제공되고 업데이트 된 현재 상태를 설명하는 필..

실제 Docker in Docker로 이미지 빌드하는 서버가 있었는데 빌드가 많이 일어나는 서버다 보니 스토리지 사용량이 점점 늘어나는 상태였음.. (이미지도 사이즈가 너무 커서 2G정도 됬었음) 따라 필요없는 오브젝트들을 정리하여 사용함 #도커 설치 경로에 따라 관리 /user/docker #도커 컨테이너 확인 docker images docker ps (-a) #레이어 정보 확인 시 docker inspect #컨테이너 접속이 필요할 경우 docker exec -it 138gjfksl /bin/sh .. #스토리지 확인 /user/docker/volume /user/docker/overlay2 #사용하지 않는 오브젝트 정리 시 docker volume prune docker system prune 끝

calico.yaml을 통해 대부분의 리소스가 배포되지만 VXLAN 설정을 위하여 해당 부분을 변경한다 DaemonSet 리소스 내 환경변수 변경 #Calico의 Default 모드는 IPIP이며 VXLAN으로 변경 vi calico.yaml #DaemonSet 오브젝트 내 env value 변경 DATASTORE_TYPE=kubernetes #IPIP -> VXLAN #Command 실행 부분 --bird-ready --bird-live 부분 삭제 CALICO_IPV4POOL_IPIP=Never CALICO_IPV4POOL_VXLAN=Always #레거시 및 RHEL 계열 설정 FELIX_IPTABLESBACKEND=NFT #프로메테우스 연동시 설정 FELIX_PROMETHEUSMETRICSENABLE..

해당 문제는 많은 문제에서 발생할 수 있지만 제가 운영하면서 발생한 문제는 이러했습니다. Node -> Clone -> 생성 문제는 이 생성된 노드가 Clone으로 복제되었을 경우인데 실제 해당 설정값이 똑같기 때문에 Kubernetes Cluster에서 해당 복제노드를 바라보게 되서 발생했습니다. IP도 다른데? 복제된 노드를 바라본다? 심지어 Subnet도 다른데? ???? 제가 처리한 방법은 해당 복제 노드에 설정된 Kubernetes와 관련된 정보들을 전부 백업으로 돌렸습니다. kubelet, docker 중지하고 kubernetes 설정정보, kubelet 설정정보 백업 돌리고.. 그러니 다시 원래 노드를 바라보게 되더라구요 #노드 IP를 확인했을 때 IP에 복제된 노드 IP로 되어 있음 kub..

실제 실무에서는 해당 서비스에 따라 노드를 분류하여 사용한다 (예 type=ingress, , type=web, type=was ...) 그러나 실제로 개발이나 검증계 쪽에서는 테스트 용으로 사용하기 때문에 한 노드에 두 서비스를 올리고 싶다는 요청을 받았다. (lable/taint 설정 안하고 그냥 막 배포하면 되는거 아니냐고!) 실제 label/taint가 설정되어 있는 노드들이기 때문에 다음과 같은 작업이 필요하다. 실제로 Taint 값이 util이라고 설정되어 있다고 한다면 NodeAffinity를 나눠서 분리하여 사용한다. 실제로 Node에 Label값을 추가하는데 실제로 service1에 service2가 추가되어 label 값이 service1, service2인 모든 노드에 배포된다. 실제..

이미지를 빌드 후 배포하였는데 파드 상태가 Pending 상태로 계속 재시작 되는 상황이 있었다. 실제로 파드 로그를 확인해 보면 ... livenessProbe Failed ... readinessProbe Failed 로그가 찍혀있는데 바로 확인 작업 진행했다. 해당 문제는 배포하였을 때 파드가 올라가는 시간이 길 경우 헬스체크 설정을 여유롭게 늘려야 하는데 그 설정이 안되어 있었다. (실제 서비스하는 파드가 로딩이 오래걸림) 정확하게는 파드가 올라가기 전 LivenessProbe와 ReadinessProbe가 설정값에 따라 상태를 확인하는데 올라가질 않으니 해당 파드를 계속 죽이고 다시 올린다. 해당 문제를 해결하려면 해당 healthcheck가 도는 시간을 늘리면 된다. #파드가 올라가기 전 Li..