예를 들면 어떤 클러스터에 적용한 템플릿에서 파드 사이 통신을 도메인으로 하도록 설정 한다면 수정 없이 다른 클러스터에 적용할 수 도 있는것이다. 또한 특정 파드나 디플로이먼트를 도메인으로 접근하도록 설정했다면 문제가 생겨서 생겨서 파드나 디플로이먼트를 재생성할 때 자동으로 변경된 파드으 IP를 도메인으로 등록한다. 자연스럽게 새로 실행한 파드로 연결할 수 있다.

IP로 통신하도록 설정했다면 IP 대역이 다를 때 템플릿에서 해당 IP 대역을 사용하도록 수정한 후 다른 클러스터에 적용해야 하므로 번거롭다.

쿠버네티스에서는 coreDNS를 사용한다.

쿠버네티스 내부 도메인은 서비스와 파드를 대상으로 사용하며 일정한 패턴이 있다. 쿠버네티스의 특정 서비스에 접근하는 도메인은 아래의 순서대로 구성한다. 기본적으로 암기하고 있는게 좋다 '서비스이름.네임스페이스.svc.cluster.local'처럼 구성한다. 물론 서비스이름이 아닌 특정파드의 도메인을 설정 할 수 있다. 특정 파드의 iP + namespace + svc.cluster.local로 구성한다. 하지만 IP를 그대로 노출 시길킨다면 도메인을 사용할 이유가 없다. 따라서 아래처럼 파드의 템플릿에 호스트네임과 서브 도메인을 설정해서 사용하는 것이 좋다.

우선 쿠버네티스에서 모든 리소스는 namespace로 구분하기 편하기 때문에 Elastic Search , Fluentd , Kibana가 배포될 namespace를 생성하자. 본인은 kube-efk로 하겠다

• Namespace

  ### 명령어로 올리지 말고 yaml 형태로 리소스 생성하자 
  apiVersion: v1
  kind: Namespace
  metadata:
  name: kube-efk

*ElasticSearch ElasticSearch는 Fluentd에서 수집된 로그를 여러 파드들이 공유받고 그 상태값을 유지해야 하기 때문에 상태값이 변하는 Deployment보다는 Statefulset이 좋겠다

apiVersion: apps/v1
kind: Statefulset
metadata:
  name: elasticsearch
  labels:
    app: elasticsearch
spec:
  replicas: 1         #노드 하나로만 구성하는 ElasticSearch를 실행할 것이므로 replicas=1로 하겠다 
  selector:
    matchLabels:
      app: elasticsearch
  template:
    metadata:
      labels:
        app: elasticsearch
    spec:
      containers:
      - name: elasticsearch 
        image: elastic/elasticsearch:6.4.0 #공식 사이트에서 이미지 정보를 받아오자
        env:
        - name: discovery.type
          value: "single-node" #Discovery.type의 value를 single-node로 설정해서 노드가 한개인걸로 설정
        ports:
        - containerPort: 9200   # ElasticSearch가 사용하는 포트인 9200,9300번을 설정
        - containerPort: 9300   
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: elasticsearch
  name: elasticsearch-svc
  namespace: default
spec:
  ports:                  # 위에서 지정한 port들을 각각 nodeport 30920,30930으로 접근 가능하도록 nodeport 필드를 설정했습니다.
  - name: elasticsearch-rest           
    nodePort: 30920
    port: 9200
    protocol: TCP
    targetPort: 9200
  - name: elasticsearch-nodecom
    nodePort: 30930
    port: 9300
    protocol: TCP
    targetPort: 9300
  selector:
    app: elasticsearch
  type: NodePort

자 이제 yaml을 저장하고 kubectl apply -f elasticsearch.yaml로 파드를 실행합니다.

localhost:30920을 통해 다음 설정이 확인되면 elasticsearch가 정상적으로 실행 된겁니다.

다음에는 로그 데이터를 시각화해서 편하게 보기위한 kibana를 배포해보도록 하겠다 필자가 쓰고도 부끄러우니 이 글은 잘 다듬어서 주말에 수정하도록 하겠다

쿠버네티스 환경에 MSA로 띄워져 있는 각각의 역할을 하는 서비스들,,, 지금은 10개 내외로 띄워져 있지만 서비스가 확장되고 여러 기능들이 생길때마다 늘어나는 파드들이 생길 것이다. 지금은 기능이 많이 없어서 어떤 서비스에서 장애가 나면 대충 어떤 파드에서 에러가 낫겟거니 유추가 가능하지만 1년뒤에도 내가 이 파드가 어떤 서비스를 제공하고 있는지 다 알지는 못할 것 같다. 임시로 모든파드에 있는 로그들을 마스터서버 디렉토리에 마운트 시켜놓긴 했지만 로그들을 일일이 보려면 여전히 불편하긴 하다.

그래서 EFK란가 뭔가를 구축해보려 한다. 필자는 아직도 저게 다 뭔지 무슨 기능을 하는지는 아직도 모른다. 지금 쓰면서 알아가보자

우선 EFK는 ElasticSearch + Fluentd + Kibana 이 3스택의 앞글자를 따와서 EFK라고 한다.

이 각 스택이 무슨 역할을 하는지 3개를 같이 쓰면 가 좋은지 까지 정리하고 이 포스팅을 마무리 해 보자

ElasticSearch

이 친구는 검색엔진이라고 한다. 많은 양의 데이터를 보관하고 실시간으로 저장,검색,분석 할 수 있게 해준다고 한다.

ElasticSearch의 특징들을 알아보고 가자

1. 멀티테넌시

• 데이터를 여러개로 분리된 인덱스들의 그룹으로 저장한다
• 서로 다른 인덱스의 데이터를 하나의 질의로 검색하여 하나의 출력으로 도출이 가능하다

2. 실시간 데이터 및 실시간 분석

• 저장된 데이터는 검색에 사용되기 위해 별도의 재시작/갱신이 불필요하다
• 색인 작업이 완료됨과 동시에 바로 검색이 가능하다
• 실시간 분석/ 검색은 데이터 증가량에 구애받지 않는다.

3. 고가용성 ElasticSearch는 하나 이상의 노드로 구성되고 각 노드에는 1개 이상의 데이터 원본과 복사본을 서로 다른위치에 나누어 저장을하여 고가용성을 제광한다

• 항상 일정한 데이터의 복사본의 개수를 유지하여 높은 가용성과 안정성을 보장한다.
• 노드가 종료되거나 실행에 실패할 경우 다른 노드로 데이터를 이동한다.

4.테이블과 스키마 대신에 JSON 구조로 인헤 모든 레벨의 필드에 접근이 쉽고, 빠른 속도로 검색이 가능해진다.

• JSON 문서를 URI로 명시 , 이 문서를 처리하기 위해 HTTP 메소드를 이용한다.

필자도 다른 포스트를 참고하고 있다보니 어려운 용어로 쓰고 있는 것 같다. 앞으로 모든 포스트가 써진 후 수정 될거 같다 미안하다.

ElasticSearch의 시스템 구조정도는 알아보고 가야할 것 같다. ElasticSearch의 하나의 클러스터는 마스터노드와 데이터노드로 구성된다.

마스터 노드는 전체 클러스터의 상태에 대한 메타정보를 관리하느 노드다. 기존의 마스터 노드가 종료되면 새로운 마스터 노드가 선출되고 마스터 노드는 요청을 처리하지 않고 데이터를 보유하지 않으므로 CPU,RAM 및 디스크와 같은 적은 리소스만 사용한다. node.master 속성을 false하면 마스터 노드에서 제외된다.

데이터 노드는 색인도니 데이터를 실제로 저정하느 노드이다. 데이터 노드는 인덱스 처리 빈도에 따라 Hot Data Node와 Warm Data Node로 나뉘어 진다. node.data속성을 false로 하면 내당 노드는 데이터를 저장하지 않는다.

FluentD

이 친구는 로그 데이터를 수집하고 변환 후 ElasticSearch의 백엔드로 전송해주는 역할을 하는 친구라고 한다. 이 친구가 먼저 로그 수집을하고 ElasticSearch로 보내주나 보다.

ElasticSearch를 너무 힘줘서 썻은니 이 친구의 특징은 간단히 설명하고 넘어가겠다

1. 데이터의 유실을 막기위해 메모리와 파일기반의 Buffer 시스템을 갖고있다.
2. Failover를 막기위한 HA 구성도 가능하다고 한다.

Kibana

이 친구는 수집된 로그를 그래프, 파트로 제공해주는 ElasticSearch용 데이터 시각화 관리도구라고 한다. Kibana를 사용하여 웹 사이트 방문자를 표시할 수도 있고 트래픽을 실시간으로 볼 수도 있다.

EFK 스택 아키텍처

본인도 조금 더 EFK를 알게되면 아키텍처까지 직접 그려서 구축해보겠다. 아키텍처를 조금 설명하자면 각 파드의 Fluentd에서 로그를 수집하고 수집된 로그를 ElasticSearch 백엔드로 변환하여 전송한다. ElasticSearch에서 데이터가 분석되고 분석된 데이터는 Kibana로 시각화하여 볼 수 있다.

참고: Kibana 대시보드를 사용하고 나머지 Fluentd ElasticSearch는 백엔드에서 작동한다.

이제 EFK 스택을 구성하는 각각의 서비스에 대해 간략하게 알아봤으니 상세 구축과정을 살펴보자

프록시는 서버와 클라이언트 간의 중계 서버로서 통신을 대신 수행하는 역할을 합니다. 여기서 프록시는 서버의 역할을 대리하기도 하고 클라이언트의 역할을 대리하기도 합니다.

이 차이로 포워드 프록시와 리버스 프록시를 나눌 수 있게 됩니다

포워드 프록시는 클라이언트와 인터넷 사이에 존재하여 클라이언트 대신 요청을 보내주는 역할을 합니다. 이러한 구조를 통해 얻는 이점은 로컬 네트워크와 인터넷 사이 오가는 트래픽을 제어할 수 있고 이를 통해 특정 불법사이트에 접속하는 것을 차단하는 기능도 할 수 있게 됩니다.

리버스 프록시는 서버 대신 클라이언트에 응답을 보내주는 역할을 합니다. 이 구조로 네트워크에 가장 끝에 있는 웹 서버의 바로 앞에 위치하기 때무에 웹 서버를 향하는 모든 요청을 처리할 수 있습니다. 또한 웹 서버의 보안 기능을 추가하거나 빠른 뤱서버 캐시를 느린 웹 서버 앞에 놓음으로써 성능을 개선할 수도 있죠

그래도 의문이 남을 겁니다. 굳이 서버를 하나 더 두는 비용이 프록시가 가지는 장점을 상쇄할까 그럼 여기서 프록시가 가지는 기능을 5가지 정도로 정리해 보겠습니다.

첫째는 필터의 기능입니다. 앞서 말한 것과 같이 특정사이트에대한 접근을 거부 시킬 수 있습니다.

둘째는 접근제어의 기능입니다. ㅁ

마스터노드: 전체 쿠버네티스 시스템을 관리 및 통제하는 쿠버네티스 컨트롤 플레인을 관장 워커 노드: 배포하고자 하는 어플리케이션의 실제 실행을 수행