BEOM_IT

Fluentd는 오픈 소스 데이터 수집기(data collector) 및 로그 전송 도구입니다. 대규모의 데이터를 처리하고 저장하기 위해 설계된 시스템에서 로그, 이벤트 및 메트릭 데이터를 효율적으로 수집, 전송 및 처리하는 데 사용됩니다. Fluentd는 로그 및 이벤트 데이터를 다양한 소스에서 수집하여 중앙 집중화된 로그 저장소나 분석 시스템에 전달할 수 있습니다. 이를 통해 다양한 데이터 소스에서 발생하는 로그와 이벤트를 통합적으로 관리할 수 있고, 데이터의 수집, 전송, 처리를 단순화할 수 있습니다. Fluentd는 다양한 데이터 소스 및 대상을 지원하며, 로그, 메시지 큐, 파일 시스템, 소켓, HTTP, TCP 등과 같은 다양한 프로토콜을 사용하여 데이터를 수집할 수 있습니다. 또한, 다양한 ..

Elasticsearch는 실시간 분산 검색 및 분석 엔진으로, 대용량의 데이터를 저장, 검색, 분석하는 데 사용되는 오픈 소스 솔루션입니다. Elasticsearch는 Apache Lucene 기반으로 개발되었으며, RESTful API를 통해 사용자가 데이터를 색인(indexing), 검색(searching), 분석(analysis)할 수 있는 기능을 제공합니다. Elasticsearch는 대량의 데이터를 신속하게 검색할 수 있는 분산 검색 엔진으로 알려져 있습니다. 여러 대의 서버에 데이터를 분산 저장하고, 데이터의 실시간 색인과 검색을 지원하여 고성능의 검색 기능을 제공합니다. 또한, 데이터의 중복성을 처리하고 가용성과 확장성을 갖추기 위해 클러스터링을 지원합니다. Elasticsearch는 JS..

Private/Public의 전체 구조는 로그를 저장하는 DB=elastic Search, 로그 수집=Fluentd, 저장한 로그를 보여주는 툴=Kibana 개인정보 로그를 제외하고 Private/Public 모두 Elastic Search에 저장 서비스,온라인배치, 일반배치, 쿠버네티스 컨트롤 플레인4종류 개인정보 로그는 public은 S3, private은 kafka를 거치지 않고 바로 전송 나머진 로그는 kafka를 거쳐 Elastic Search에 저장 구조: Pod생성(log 생성) ->FluentD -> Kafka -> 설치형 FluentD -> ElasticSearch(Managed) 로그양이 적다면 Kafka 단계를 건너뛰고 FluentD->ElasticSearch Kafka는 설치형으로 ..

oc 명령어를 사용해 ns를 조회하는 권한이 없을때 oc get ns와 oc get ns [네임스페이스명]을 입력했을 경우 차이! oc get ns 명령어는 현재 사용자가 조회 가능한 모든 네임스페이스를 출력합니다. 따라서 현재 사용자가 네임스페이스 조회 권한이 없는 경우에는 oc get ns 명령어를 실행해도 어떤 네임스페이스도 출력되지 않습니다. 반면에 oc get ns [네임스페이스명] 명령어는 지정된 네임스페이스의 정보를 출력합니다. 따라서 현재 사용자가 지정된 네임스페이스의 조회 권한이 없더라도 해당 네임스페이스에 대한 정보를 출력할 수 있습니다. 그러나 해당 네임스페이스를 제어하거나 수정할 수 있는 권한이 없는 경우에는 오류 메시지가 출력됩니다.

쿠버네티스에서 노드(Node)는 애플리케이션이 실행되는 호스트 머신입니다. ex)VM,물리적서버 노드는 일반적으로 가상 또는 물리적인 서버이며, 애플리케이션의 실행을 담당하는 작업자 노드(Worker Node)와 쿠버네티스 시스템 컴포넌트를 실행하는 마스터 노드(Master Node)로 구성됩니다. 노드에는 컨테이너(Container)가 실행됩니다. 컨테이너는 애플리케이션을 실행하는 단위이며, 하나의 노드에는 여러 개의 컨테이너가 실행될 수 있습니다. 노드에 실행되는 컨테이너는 독립적인 공간을 가지고 있으며, 다른 컨테이너나 호스트 머신에서 실행되는 프로세스와 격리되어 있습니다. 컨테이너는 가볍고 빠르게 배포, 확장, 관리할 수 있으며, 여러 컨테이너를 동일한 노드에서 실행하면 노드의 리소스를 효율적으로..

카나리 배포(Canary Deployment)는 새로운 버전의 애플리케이션을 릴리스하기 전에 먼저 일부 사용자에게 테스트를 진행하는 방식 모든 사용자에게 동일한 새로운 버전의 애플리케이션을 릴리스하는 대신, 일부 사용자에게 새로운 버전의 애플리케이션을 제공하고 이를 모니터링하며, 안정적인 상태인 경우 나머지 사용자에게 롤아웃 카나리 배포는 예상치 못한 버그, 성능 문제 등을 빠르게 감지하고 대처할 수 있으며, 전체 애플리케이션의 안정성을 높이는 데 도움이 됩니다. 이를 위해서는 새로운 버전의 애플리케이션과 이전 버전의 애플리케이션이 함께 실행되어야 합니다. 카나리 배포를 구현하기 위해 로드 밸런싱, 라우팅 규칙, 그리고 롤백 전략 등을 설정할 수 있는 컨트롤러를 사용 Istio Linkerd etc...

그물 형태의 통신이나 경로를 제어하는 개념 애플리케이션의 서로 다른 부분이 서로 데이터를 공유하는 방법을 제어하는 ​​방법 대부분 트래픽 컨트롤 기능 ex) 트래픽의 99%는 이전 이미지로 기동중인 디플로이에 전송하고 1%를 신규 디플로이에 전송해 서비스 환경에 단계적으로 카나리 배포 가능 카나리=배포 전 일부 인원 테스트 기능 트래픽 시프팅 서킷 브레이커 에러 반환 폴트 인젝션 속도 제한 재시도

오픈소스 소프트웨어 C++로 만들어진 엔보이를 사용하여 쿠버네티스 클러스터에 서비스 매시를 구현 서비스매시: 그물 형태의 통신이나 경로를 제어하는 개념 istio는 서비스 매시를 쿠버네티스 클러스터 외부의 VM이나 물리서버로 확장 여러 클러스터를 istio를 연계함으로써 서비스 매시를 구성한 멀티 클러스터 환경 구축 이스티오 아키텍처 이스티오는 각 파드안에서 Sidecar로 Envoy 프록시가 들어가 있는 형태 마이크로서비스간 통신은 엔보이를 반드시 통과 Envoy Sidecar 작동 클라이언트 -> envoy -> app -> envoy -> envoy -> app

우선 순위 : BestEffort > Burstable > Guaranteed 컨테이너의 리소스 설정으로 결정됨 Guaranteed (보장, 개런티드) 모든 컨테이너에 requests, limit 설정 request, limit의 memory, cpu 모두 설정 각 컨테이너의 request와 limit의 memory, cpu 값이 같음 apiVersion: v1 kind: Pod metadata: name: qos-demo namespace: qos-example spec: containers: - name: qos-demo-ctr image: nginx resources: limits: memory: "200Mi" cpu: "700m" requests: memory: "200Mi" cpu: "700m"..

$ oc get ns -> ns 조회 $ oc describe no -n [ns] ->특정 ns의 node를 조회 $ oc describe no | more -> node 조회(몇 개 없다면..) Allocated resource: 항목의 CPU/Memory 의 Requests , Limit을 확인후 배포 결정 ex) node 2개 (12core/24Gi) A-node 6core/12Gi 사용중(50%/50%) $ oc adm top no -n [ns] 조회시 CPU/Memory가 (6%/46%)사용중 이럴경우 50%만 허용