source

Docker Swarm 클러스터를 모니터링 할 수 있는 방안은 여러가지가 있지만 Grafana를 이용한 방안을 알아보겠다. Docker Swarm 클러스터 구성 방법은 이전 포스팅 글에서 확인할 수 있다. # Docker Swarm 클러스터 구성 # Docker Swarm 클러스터 구성 Docker Swarm 이란 컨테이너를 관리하는 Orchestration Tool 중의 하나이다. Orchestration Tool 이란? 컨테이너의 단순 배포 뿐만이 아니라 확장, 네트워킹 등을 자동화하여 수백 또는 수천 개의 컨테이너를 �� skysoo1111.tistory.com Step 1. Docker 데몬 메트릭 노출 및 Docker 재기동 $ sudo vi /etc/docker/daemon.json { "me..

Docker Swarm 이란 컨테이너를 관리하는 Orchestration Tool 중의 하나이다. Orchestration Tool 이란? 컨테이너의 단순 배포 뿐만이 아니라 확장, 네트워킹 등을 자동화하여 수백 또는 수천 개의 컨테이너를 보다 효율적으로 관리할 수 있는 기능을 지원하는 도구이다. Orchestration Tool 장점 단점 Docker Swarm •Docker 의 모든 기능이 내장되어 있다. •Docker 외 별도의 툴 설치가 필요하지 않다. •타 Orchestration Tool에 비해 다루기 쉽다. •타 Orchestration Tool에 비해 기능이 단순하다. •초대형 노드 클러스터링에는 무리가 있다. Kubernates •현재 가장 많이 쓰이고 있는 툴이다. •내장된 기능이 많아..

Pod Security Policy (이하 PSP) 란? k8s에는 SecurityContext라는 기능이 존재한다. SecurityContext는 Container의 보안 기능을 정의하는 것인데, 개인적으로 PSP는 이 SecurityContext의 확장판이라고 생각한다. PSP(포드 보안 정책)은 포드 사양의 보안 관련 측면을 제어하는 ​​클러스터 수준 리소스이다. PSP 객체는 관련 필드에 대한 기본값 뿐만 아니라 시스템에 적용하기 위해 포드가 실행해야 하는 조건 세트를 정의한다. 관리자는 다음을 제어 할 수 있다. 제어 목록 필드명 Container의 실행 권한 privileged 호스트 네임 스페이스의 사용 hostPID, hostIPC 호스트 네트워킹 및 포트의 사용 hostNetwork, h..

go지난 시간에 HPA 구성을 통해 CPU, Memory에 따른 POD의 자동 증감을 실습해봤다. 그리고 Memory HPA 테스트에서 나온 확인 사항으로 HPA가 대상 서비스의 CPU의 target 인식을 못하던 이슈가 있었다. 오늘은 해당 이슈의 원인을 찾아서 관련 내용을 포스팅하겠다. 먼저 지난 테스트 때의 HPA의 상황이다. TARGETS의 CPU가 으로 표시되는 것을 확인했다. 결론부터 말하자면 원인은 HPA가 감시하는 대상 서비스의 Resource Limits 값을 주지 않았기 때문이다. 해결 방안 내가 HPA로 감시하려는 서비스의 설정에서 spec에 아래 Resource Limits 설정을 추가해줘야 한다. CPU는 필수이고, 메모리는 안해도 HPA가 TARGETS 값을 읽어오는데 아무런 지..

이 글은 앞으로 계속 업데이트 될 것이다. k8s에서 자주 사용하거나 유용했던 명령어들 정리하는 글이다. k8s 공식 문서로 명령어 / 사용법이 잘 나와있다. https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#scale 1. k8s replica 수 조정 # 특정 replicaset의 replica 수 조정 $ kubectl scale --replicas=3 rs/ # 특정 yaml 서비스의 replica 수 조정 $ kubectl scale --replicas=1 -f 1.hello-deployment.yaml

지난 글 (# k8s Horizontal Pod Autoscaler (HPA) 실습 - 1)에 이어서 이번엔 Memory 부하 테스트에 따른 Autoscaling을 실습을 진행하겠다. 사실 k8s를 공부하면서 가장 힘든 것은 버전 up에 따른 이슈들인데, 버전 up에 따른 API 변경 사항이 너무 많다. 물론 기본 예제들은 공식 사이트에 잘 나와있으나, k8s 입문자들이 관련 예제를 블로그 등의 정보를 가지고 조금 응용해보려고 하면 버전 문제 등으로 금방 막혀버린다. 그래서 내가 겪어봤을 때 가장 좋은 방법은 무턱대고 블로그 자료를 복붙 하기 보다 역시나 공식 문서를 활용하는 것이다. k8s의 API 문서를 보고 적어도 내가 적용하려는 버전의 해당 기능과 관련된 필드에는 어떤 값들이 들어가는지, 바뀐 것..

지난 글(# k8s Pod Autoscaling 개념)에서 쿠버네티스의 Pod Autoscaling 개념에 대해 간단히 알아보았으니, 이번엔 실제 예제를 통해 어떻게 동작하는지 확인해보자. [실습 순서] 1. Metrics Server 기동 2. k8s 공식 문서 예제 실습 k8s의 Pod Autoscaling 기능을 구현하려면 반드시 선행되어야 하는 작업이 있다. 바로 Metrics Server 기동이다. Autoscaling을 하려면 k8s가 각 pod, node의 리소스 상태를 모니터링 할 수 있어야 한다. 이때, 리소스 상태 모니터링을 위해 사용되는 것이 Metrics Server이다. Metrics Server 없이 Autoscaler를 사용하려고 하면 아래와 같은 에러가 발생할 것이다. fai..

k8s Pod Auto Scaling 이란? 클라우드의 핵심은 리소스 관리이다. 이는 서비스 중인 Application의 리소스가 부족할 때, 쿠버네티스가 이를 스스로 파악하여 적절한 대처(Pod를 늘리는 것, 리소스를 추가 할당 등)를 해주는 것을 말한다. 이것을 Auto Scaling이라 부르며, 쿠버네티스에서는 아래 3가지 방안으로 그 기능을 제공한다. 1. Horizontal Pod Autoscaler (HPA) HPA는 클러스터의 Pod 복제본 수를 조정 Pod 이동은 필요에 따라 함(CPU 또는 사용자 정의 메트릭) 다양한, 외부 및 사용자 정의 메트릭 (metrics.k8s.io, external.metrics.k8s.io 및 custom.metrics.k8s.io)에 따라 포드 (Pod)를..

[ 설치 환경 ] - centos7 - Docker version 19.03.2 - GeForce 940M - k8s 1.15.3 [ docker 설치 ] $ sudo yum remove docker docker-client docker-client-latest docker-common docker-latest docker-latest-logrotate docker-logrotate docker-engine docker-ce $ sudo yum install -y yum-utils device-mapper-persistent-data lvm2 $ sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.rep..

haproxy 설치 후 기동할 때 아래와 같은 에러가 발생할 수 있다. [ALERT] 015/013939 (22640) : Starting frontend public: cannot bind socket [0.0.0.0:80] 이는 SELinux 보안 정책과 충돌이 나서 발생하는 것이다. haproxy가 생성한 포트를 모두 허용하도록 설정하면 된다. $ setsebool -P haproxy_connect_any 1 끝