'2018/05'에 해당되는 글 2건

Stateless Application

• Web front-end 와 같이 디스크에 중요한 데이터가 없는 것들
• 필요한 만큼의 여러 개의 똑같은 컨테이너를 시작/종료할 수 있는 것들
• Ephemeral 특성 - 컨테이너가 죽으면 내부에 보관중인 데이터는 사라짐
• Instance 별의 특별한 데이터가 없을 것 

Stateful Application

• Container-specific 특성(주로 호스트/도메인명, 드물게는 IP 주소)
• 암호, 인증키, 설정값 등의 Instance 개별 할당
• 적용가능 Application(Clustered) 들은 다음과 같음
  : MySQL(Galera Cluster) Mongodb(Replicaset), Zookeeper ensemble, PostgreSQL cluster, Redis, ElasticSearch, etc.

Kubernetes 에서는 Stateful Application의 오케스트레이션을 위해서 StatefulSet(workload API Object, Kubernetes 1.9 버전부터 정식 지원) 형태로 구현되어 있는데,  본 5편으로 이루어진 시리즈에서는 다음의 내용들을 직접 구현하는 방법들을 정리해 두기로 한다. 

여기서 보여지거나 언급되는 각 솔루션들의 구현 형태는 여러 다양한 변형이 존재할 수 있으며, Kubernetes 1.9.x 버전에서 정상 작동하는 실제적 내용으로 수정/검증, 편집된 것이며, 레퍼런스가 있을 경우 아래에 별도 명시한다.

• Nginx Web Cluster(본 편 ... 1/5)
• Mongodb Replicaset by StatefulSet(2/5)
• Mariadb Galera Cluster by StatefulSet and etcd(3/5)
• Mariadb pxc-cluster(4/5)
• Zookeeper Ensemble by StatefulSet(5/5)

Nginx Web Cluster 구현

• Running Kubernetes Cluster - v1.9 이상
• Persistent Storage - GlusterFS(Hyper-converged 또는 External)

# Service/endpoint for load balancing the client connection from outside
# By NodePort
---
apiVersion: v1
kind: Service
metadata:
  namespace: ns-statefulset
  name: nginx-svc
  labels:
    role: nginx
spec:
  type: NodePort
  ports:
    - port: 80
      name: client
      nodePort: 30080
  selector:
    role: nginxrs

# A headless service to create DNS records
---
apiVersion: v1
kind: Service
metadata:
  namespace: ns-statefulset
  name: nginx-hs
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
    targetPort: 80
  clusterIP: None
  selector:
    role: nginxrs

# StatefulSet for nginx cluster
---
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  namespace: ns-statefulset
  name: nginx-ss
spec:
  serviceName: nginx-hs
  replicas: 3
  template:
    metadata:
      labels:
        role: nginxrs
        environment: test
    spec:
      containers:
      - name: nginx
        image: gcr.io/google_containers/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www-pvc
          mountPath: /usr/share/nginx/html
      terminationGracePeriodSeconds: 10
  volumeClaimTemplates:
  - metadata:
      name: www-pvc
      annotations:
        volume.beta.kubernetes.io/storage-class: glusterfs-storage
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 100Mi

StatefulSet 만의 특징적인 사항들의 확인

[Service와 Pod의 네트워크 ID 확인]

Busybox pod 를 통해 StatefulSet의 Headless Service(nginx-hs)와 Pod의 DNS 정보를 확인

* Headless service는 StatefulSet의 도메인을 구성하는 단위이며, ${서비스명}.${네임스페이스}.svc.cluster.local 형식의 도메인이 만들어 짐

* 위의 yaml 파일 내용을 보면 headless service의 spec: 에서 clusterIp: None 으로 지정되어 있는 것이, 일반적인 kubernetes service와 극명하게 차이가 나는 부분이며, 이를 통해 headless service와 연결되는 특정한 Pod에 직접 access 가 가능하게 됨 

* 각 Pod의 이름은 ${StatefulSet 이름}-${순번} 형식으로 결정되며,Pod의 도메인 형식은 ${StatefulSet 이름}-${순번}.${서비스명}.${네임스페이스}.svc.cluster.local 이 됨

[각 Pod의 고유 정보를 설정하고 Scale-out, Self-healing 확인]

* StatefulSet 의 replicas 를 4로 증가하고 nginx 의 index.html 생성

* 일반 service인 Nginx-svc 서비스(NodePort 30080으로 expose 됨)로 curl 접속, 각 Pod로 접속이 분배(로드밸런싱) 됨을 확인

* Pod nginx-ss-1를 삭제하였으나 self-healing이 동작하여 StatefulSet 의 향상은 유지되어, pod nginx-ss-1 에 원래의 Persistent Volume이 연결됨(해당 Pod 고유의 기존 데이터도 그대로 유지)

* Busybox 에서 pod nginx-ss-1의 웹서버에 wget으로 접속, 웹서비스가 정상 동작됨을 확인

[StatefulSet과 관여되는 서비스 Clear, Persistent Volume Clear]

* StatefulSet에 연결된 Persistent Volume이 삭제되지 않을 경우, 확인 후 명시적으로 Clear 해 주어야 함. 이는 scale-in을 하여 Pod가 삭제되는 경우에도 동일하게 발생할 수 있으며, 글을 쓰기 시작한 시점에는 이러한 문제를 해결하고자 별도의 노력이 필요한 상황이며, 아래 2번째 레퍼런스를 참고해 볼 필요가 있음.

[References]

• https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/
• https://medium.com/@marko.luksa/graceful-scaledown-of-stateful-apps-in-kubernetes-2205fc556ba9

- Barracuda -

개요

GitLab 을 위한 Custom Hook은 다음의 3 가지 중 하나로 구현된다(Community Edition 기준).

• pre-receive: Git 서버가 클라이언트로부터 Push 요청을 받은 즉시 수행되며, 스크립트에서 non-zero 값을 return 하면 Push 요청은 reject 된다. Push 요청에 대한 값은 스크립트 내에서 stdin 스트림 값을 읽어서 사용 가능하다
• update: pre-receive 와 유사하지만, pre-receive 는 한 번의 Push에 대해 단 한 번 수행되며, update는 각각의 Branch 마다 triggering 되는 점이 다르다. 따라서 여러 Branch에 Push 를 수행하게 되면 특정한 브랜치에 대해서만 reject 되게 처리되게 하고 싶을 떄 사용한다
• post-receive: Push 에 대한 모든 처리가 완료된 직후에 수행된다. Push 데이터에 대해 stdin 을 참조해서 사용하면 되며,  주로 사용자에게 메일 발송이나 CI 서버로의 triggering 또는 이슈 트래킹 시스템으로 티켓을 업데이트할 때 사용한다

스크립트 pre-receive 구현 및 활용 방법

• pre-receive-commit-msg-check.py 파일 최종 버전을 GitLab 서버의 /root/custom_hooks_src에 저장해 둔다(백업/확인용, option 사항)
• pre-receive-commit-msg-check.py 파일 최종 버전을 /root/custom_hooks 에 pre-receive 라는 이름으로 저장하고, chmod a+x pre-receive, chown git.git pre-receive 로 설정한다
• copy_custom_hooks.sh 스크립트의 target_path_list 에 pre-receive Hook 을 적용할 repository 정보를 등록한다

• copy_custom_hooks.sh 파일을 적당한 위치에 저장(/root/copy_custom_hooks.sh)해 두고 실행하면 지정된 repository 의 해당 path 로 복사된다(copy_custom_hooks.sh 파일의 내용은 다음과 같다)

• 본 pre-receive 스크립트의 commit 제약 조건은 다음과 같다

• pre-receive 의 원본에 해당되는 pre-receive-commit-msg-check.py 스크립트의 내용은 다음고 같으며, GitHub 의 여기에 공개되어 있다

- Barracuda -