파드에 Requests/Limits 설정에 따라 자동으로 QoS Class 값이 설정되게 되어 있습니다. QoS Class란 kubernetes가 컨테이너에 oom score를 설정할때 사용됩니다. oom score는 OOM Killer에 의해 프로세스를 정지시킬 때 우선순위 값으로 -1,000(최고 순위) ~ 1,000(최저순위) 범위에서 설정합니다. 따라서, kubernetes의 리소스가 부족할 때 즉, 노드에 리소스가 부족할때 QoS에 따라 어떤 파드의 컨테이너를 kill 할지 결정합니다. □ BestEffort pod의 어떤 container내에도 Request와 Limit이 미설정 되어있는 경우입니다. 이럴경우 limit을 설정하지 않았기 때문에 노드에 유후 자원이 존재한다면 제한 없이 모든 자..
Kubernetes에는 세가지 헬스 체크 방법이 있습니다. Liveness Probe, Readiness Probe, Startup Probe 라는 세 가지 헬스 체크 방법이 있습니다. 모두 역할이 다를 뿐 설정 가능한 내용은 똑같고 spec.containers에 설정하게 됩니다. Probe 종류 역할 실패 시 동작 Liveness Probe 파드 내부의 컨테이너가 정상 동작중인지 확인 컨테이너 재기동 Readiness Probe 파드가 요청을 받아들일 수 있는지 확인 트래픽 차단 (파드를 재기동 하지 않음) Startup Probe 파드의 첫 번째 기동이 완료되었는지 확인 다른 Probe 실행을 시작하지 않음 □ Liveness Probe 파드 내부의 컨테이너가 정상적으로 동작 중인지 확인하기 위한 헬..
MSA 아키텍처를 많이 지향하고 있는 추세인데, 해당 트렌드에 맞춰서 무중단으로 안전하게 배포할 수 있는 전략이 많이 나오고 있습니다. 해당 포스팅에서 Rolling 배포 및 카나리 블루/그린 배포에 대해서 설명하고 kubernetes deployment에 업데이트 전략에 대해 다뤄보겠습니다. 보통 Rolling 업데이트, 카나리, 블루/그린 배포는 무중단으로 배포할 수 있는 기법입니다. □ Rolling 배포 Rolling 배포의 정의는 사용중인 서비스 내에서 새 버전을 점진적(순차적)으로 교체하는 것을 말합니다. 관리가 편하지만, 배포 중 하나의 서비스 수가 감소되므로 서버 처리 용량을 미리 고려해야 합니다. Rolling 배포는 사용 중인 Pod 내에서 새 버전으로 점진적으로 교체하는 것으로 무중단..
해당 포스팅은 "쿠버네티스 완벽 가이드" 책을 많이 참고해서 작성되었습니다. Kubernetes의 스케줄링에는 필터링 과정과 스코어링 과정이 있습니다. * 필터링(단정)에서는 스케줄링하는 파드가 할당 가능한 노드를 계산합니다. 예를들어 파드를 스케줄링하는 데 충분한 리소스가 있는지 또는 필수 조건으로 지정한 레이블을 가진 노드인지 등을 체크합니다. * 스코어링(우선순위)에는는 필터링된 후 노드 목록에 순위를 매겨 가장 적합한 노드를 계산합니다. 우선순위 조건으로 지정한 레이블을 가진 노드를 우선적으로 처리합니다. 따라서, 필터링이나 스코어링을 지정하지 않아도 Kubernetes가 자동으로 계산되어 스케줄링에 사용되는게 가장 큰 장점입니다. Kubernetes 스케줄링 분류는 다음과 같습니다. Kubern..
□ 고가용성 서버와 네트워크, 프로그램 등이 오랜 기간 동안 지속적으로 정상 운영 가능한 성질을 말합니다. 고가용성은 흔히 가용한 시간을 99%, 99.9% 등과 같은 비율 값으로 표현합니다. 즉, 가용성을 극대화 시키는 구성을 말하는 것으로 클러스터링, 이중화, RAID는 HA를 이루기 위한 방식이라고 볼 수 있습니다. 고가용성을 달성하기 위한 수많은 설계 방법이 있지만, 대표적인 몇 가지 예시로는 다음과 같습니다. 1) 네트워크 연결의 이중화 구성 2) LAG 3) 로드밸런서 4) RAID 방식의 스토리지 보통 AWS에서 아래처럼 이중화를 위해 물리적으로 떨어져있는 영역인, Availibility Zone 줄여서 AZ라고 불리는 개념이 존재합니다. AZ를 통해 일반적으로 같은 데이터 센터에 서버만 여..
인스턴스를 운영하다보면 디스크 사이즈가 부족해 볼륨을 늘려야 하는 상황이 생깁니다. 해당 내용은 AWS EC2 디스크 용량을 늘리는 방법입니다. 크게 EBS 볼륨 증설, 파일 시스템 확장 작업을 진행해야 합니다. □ EC2 대쉬보드 -> EBS -> 볼륨 ▶ 먼저 AWS 콘솔에 접속해 EBS 볼륨 수정을 진행합니다. ▶ 볼륨수정에서 자신이 원하는 스토리지를 증설해 줍니다. ▶ 위의 작업을 완료하면 아래처럼 상태가 in-use-optimizing 상태로 확장중인 상태가 표시됩니다. (아래 세부사항에 친절하게 %도 다 알려주며 조금 시간이 지나면 완료상태로 바뀝니다.) □서버 볼륨의 시스템 확인 및 블럭 장치 목록 확인 ▶ 기존에는 아래처럼 기본 50GB 디스크 용량을 가지고 있는걸 확인할 수 있습니다. [..
pinpoint pinpoint는 application의 프로파일링 정보를 추출하는 Agent와 데이터를 수집하는 Collector, 수집된 데이터를 시각화하는 Web UI, 데이터를 저장하는 HBase로 구성되어있습니다. Agent: 프로파일링이 필요한 애플리케이션 JVM에 java agent 형태로 추가되어 Collector에 프로파일링 정보를 전송 Collector: Agent가 보낸 프로파일링 정보를 수집하고 HBase에 저장 Web UI: 수집된 데이터를 다양한 형태의 정보로 사용자에게 Web을 통해 제공 HBase: 수집된 데이터를 저장하고 조회하는 빅데이터용 데이터베이스 install Pinpoint 공식 Github에 보면 Installation guide 와 Quick Installati..
istio gateway는 클러스터 외부에서 발생하는 트래픽으로부터 클러스터에 대한 액세스를 보호하고 제어하는 역할을 합니다. 또한 istio gateway는 로드 밸런싱 및 가상 호스트 라우팅의 역할을 담당합니다. 아래 그림처럼 client 1이 svc-a.foo.com으로 외부에서 요청이 들어오면 맨 먼저 istio gateway에 도달하게 되고 미리 정의해둔 gateway에 svc-A -> 1.1.1.1/2.2.2.2 처럼 hostname과 path의 규칙을 따라 svc-A로 트래픽을 전달하게 됩니다. 제가 생각하는 흐름은 간단하게 client -> istio-ingressgateway -> gateway -> virtual service -> svc -> pod 처음 istio를 설치하면 isti..
Gitlab root password를 변경하는 방법을 살펴보겠습니다. □ 현재 Gitlab을 Docker Container 형식으로 올려놓아서 먼저 Container로 접속합니다. [root@cicd-server gitlab-runner]# docker exec -it 111333 bash □ gitlab console을 실행합니다. root@111333:/# gitlab-rails console -e production -------------------------------------------------------------------------------- GitLab: 13.5.3 (eaa194f15e6) FOSS GitLab Shell: 13.11.0 PostgreSQL: 11.9 -----..
Mariadb 클라이언트에서 mysql 서버에 접속할 때 기본적으로 평문 통신을 합니다. 이경우 데이터들을 그대로 네트워크상에 노출시키며, 이로인해 스니핑과 같은 공격으로 인해 중요 정보가 외부에 유출될 수 있습니다. 서버-클라이언트 사이에 전송되는 데이터를 SSL/TLS 프로토콜을 이용하여 암호화하여 DB 정보가 노출되지 않게 방지할수있습니다. MariaDB는 SSL이 지원되지만 기본적으로 아래처럼 disable상태입니다. 서버가 ssl connection을 지원한다면, 값은 YES 그렇지 않고 ssl지원이 compile안됐다면 값은 no가 됩니다. MariaDB [(none)]> show variables like 'have_ssl'; +---------------+----------+ | Varia..