Zookeeper는 안정적인 분산 조정(distributed cordination) 처리를 가능하게 해주는 오픈소스 서버

- 설정 정보 유지, 이름 지정, 분산 동기화 및 그룹 서비스 제공을 위한 중앙 집중식 서비스

- 분산 처리 시스템을 구성할 때 서버 간의 정보 공유, 서버 상태 체크, 동기화에 대한 락 처리를 수행하는 대표적인 오픈소스

특징

1) zookeeper는 심플하다. 주키퍼는 분산된 프로세스가 znode로 불리는 네임스페이스가 cordinate(조정)할 수 있다. 높은 성능과 고가용성으로 대규모 분산처리 시스템에 적합하다. 

2) zookeeper는 복제된다. 조정 된 분산 프로세스와 마찬가지로 ZooKeeper 자체는 ensembl이라는 일련의 호스트를 통해 복제된다. 

클라이언트는 단일 zookeeper 서버와 연결하여 데이터를 주고받으며 감시 이벤트를 통해 연결 유지 중이라는 것을 알리는 heatbeat를 주고 받는다. 만일 특정 상황으로 인해 연결이 끊어지면, 다른 서버에 연결될 것이다. 이를 통해 SPOF(SinglePoint of Failure)가 되는 일을 막는다.

3) zookeeper는 순서화된다. ZooKeeper는 모든 ZooKeeper transaction의 order를 반영하는 숫자로 각 업데이트에 도장을 찍는다.

4) zookeeper는 빠르다. 쓰기보단 읽기 작업 성능에서 빠르다.

5) 네임스페이스는 파일시스템 계층과 유사하며, 디렉토리 구조의 각 노드에 데이터는 저장한다. 파일 시스템과 다른 점은 각 노드에 자식 노드의 데이터 혹은 관련된 데이터가 포함된다.

Znode

- Ephemeral Node(임시노드): 해당 노드는 노드를 생성한 클라이언트의 연결 세션이 유지될 때만 유효하다. 

- Persistance Node(영구노드): 데이터를 강제로 삭제하지 않는 이상, 영구적으로 저장되는 노드이다.

- Sequence Node(시퀀스 노드): 노드를 생성할 때 자동으로 sequence 번호가 붙는 노드. 주로 분산 락을 구현하는데 이용한다.

Watches

- 주키퍼는 watch라는 콘셉을 제공하는데, 클라이언트는 노드에 watch를 설정할 수 있다. znode가 업데이트되면 watch는 트리거가되고 제거되며 클라이언트는 노드가 변경되었다는 패킷을 수신하게 된다. 예를 들어 watch를 설정한 상태에서 클라이언트와 서버의 연결이 끊어지면 연결이 끊어졌다는 local 알림을 받을 수 있을 것이다.

API

- API는 다음과 같은 점을 지원한다.

1) create: 노드 생성

2) delete: 노드 삭제

3) exsists: 노드가 존재하는지 테스트

4) get data: 노드로부터 데이터 read

5) set data: 노드에 데이터 wrtie

6) get children: 자식 노드 검색

7) sync: 데이터가 전파될 때까지 대기

http://zookeeper.apache.org/

http://zookeeper.apache.org/doc/r3.5.6/zookeeperOver.html

https://bcho.tistory.com/1016

http://helloworld.naver.com/helloworld/textyle/294797

Secret

• 보안유지가 필요한 자격증명 및 개인 암호화 키 같은 중요한 정보를 저장하고 분류하기 위해 제공되는 리소스

1) 특징

• 패스워드 같은 기밀 정보를 Base64 인코딩으로 만들 수 있다.
• key=value 쌍으로 사용한다.
• 환경 변수로 secret 정보를 컨테이너에 전달할 수 있다.
• 볼륨의 파일로서 시크릿 정보를 저장할 수 있다.
• 메모리에 저장된다.
• 시크릿 크기가 너무 커지면 쿠버네티스의 apiserver나 kubelet의 메모리를 많이 차지하게되기 때문에 개별 시크릿의 최대 크기는 1MB까지 정의한다.

2) 종류

• Built in 시크릿(default-token secret)
  : 클러스터 내부에서 API 이용 시 사용됨
  : 내부에서 사용되는 계정인 Service account를 생성하면 자동으로 secret 생성
  : 만들어진 secret으로 해당 service account가 권한을 가지고 있는 API 접근 가능

• 사용자 정의 시크릿
  : 말그대로 사용자가 정의한 시크릿
  : create 명령어를 사용하여 생성할 수 있고, yaml 파일에 정의해서 생성할 수도 있음

3) Secret vs ConfigMap

• 민감하지 않은 일반 데이터는 configMap 리소스를 사용한다.
• 중요 데이터가 포함되어 있으면 Secret 리소스를 사용하는 것이 좋다.

4) Built in Secret

• 모든 Pod에는 자동으로 연결된 secret 볼륨이 존재한다.

$ kubectl describe pod [name]

Mounts:

      /var/run/secrets/kubernetes.io/serviceaccount from default-token-kf7wl (ro)


---------------------------

Volumes:

  default-token-kf7wl:

    Type:        Secret (a volume populated by a Secret)

    SecretName:  default-token-kf7wl

    Optional:    false

$kubectl describe secret default-token-kf7wl

Name:         default-token-kf7wl

Namespace:    default

Labels:       <none>

Annotations:  kubernetes.io/service-account.name=default

              kubernetes.io/service-account.uid=7223520f-e519-11e9-876a-025000000001


Type:  kubernetes.io/service-account-token


Data

====

ca.crt:     1025 bytes

namespace:  7 bytes

token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImRlZmF1bHQtdG9rZW4ta2Y3d2wiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGVmYXVsdCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjcyMjM1MjBmLWU1MTktMTFlOS04NzZhLTAyNTAwMDAwMDAwMSIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmRlZmF1bHQifQ.P4FnIdYC_JHXCM-RyboMkotOEkf2sRhRgXkyS9nUezIOddQ3lQGdsPI8ZXiIq1PPZN2KrXUMjq6B7rDJw3_A-zN2e1UwQfemPqllhrSNduy1WWwJTCsv71rjZmLrmrA5klmgW7DzizfLNgKY6hLpK7lSlA3pxIDzkdtYhG9AQ4oXPTym6LUCgPCO2DhonMVbbkQtRI2JoWvCdxS6geea-Kne4Op82lWFErv5zP0hmUhb5vyiFXGWBQYp-CZehiwAuNNg44_cyz3d6r_51oJAwcKiovxPRkqjJqiJfxG5gjDlPu6GT9Enbbh5Jo2x3hHYXwBqOV8CV0iT7ZyU_p2eEA

=> secret volume을 통해 제공되는 3가지 항목은 kubenetes API 서버와 안전하게 통신하기 위해 필요하다.

=> 즉 https 통신을 하기 위함

5) 사용자 정의 시크릿

• mac이나 linux에서 다음과 같은 명령어로 문자열을 base64로 인코딩 할 수 있다.

• base64로 인코딩하는 이유는 ssl인증서나 binary 데이터의 지원을 위해 사용된다.

$ echo password | base64

cGFzc3dvcmQK

5.1) 시크릿 생성 - 명령어

$ echo -n ‘sa’ > ./username.txt
$ kubectl create secret generic h2-user-name --from-file=./username.txt

5.2) 시크릿 생성 - yaml 파일

$ kubectl describe secret mysqlsecret

Opaque 및 타입에 대해 알아보기

https://github.com/kubernetes/kubernetes/blob/7693a1d5fe2a35b6e2e205f03ae9b3eddcdabc6b/pkg/apis/core/types.go#L4394-L4478

5.3) 시크릿 적용

<simple-database-secret.yaml>

5.4) 환경변수 조회

$ kubectl exec health-check-app-86758956dd-lqb2t -- env | sort

....

KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_PORT_HTTPS=443
LANG=C.UTF-8
MH_ADDR=192.168.137.100
MYSQL_DATABASE=sample
MYSQL_PASSWORD=root
MYSQL_PORT=3306
MYSQL_USER=root

참조: https://kubernetes.io/docs/concepts/configuration/secret/

namespace

 쿠버네티스는 클러스터 안에 가상 클러스터를 또 만들 수 있다.

- kubectl get namespace

pod

1) yaml 파일 정의해서 생성하기

simple-pod.yaml

$ kubectl apply -f simple-pod.yaml

2) pod 정보 조회

$ kubectl get pod

$ kubectl get pods --all-namespaces -o wide

3) pod 내부 컨테이너 실행

$ kubectl exec -it health-check-app sh -c health-app

4) 로그 보기

$ kubectl logs health-check-app

5) pod 삭제

$ kubectl delete pod health-check-app

6) 리소스 전체 삭제

$ kubectl delete -f simple-my-pod.yaml

7) 로컬 포트 포워딩

$ kubectl port-forward health-check-app 8080:8080 

replicaset

: 똑같은 정의를 갖는 파드를 여러 개 생성하고 관리하기 위한 리소스

simple-replicaset.yaml

1) replicaset 생성

 $ kubectl apply -f [file]

2) label 조회

$ kubectl get pods --show-labels

3) replicatset 삭제

$ kubectl delete rs health-check-app --cascade=false 

  : cascade default는 true, pod이 삭제됨

4) pod 삭제할 경우

  : replicaset에 의해 복제된 개수가 유지되기 때문에 자동으로 Pod을 추가 생성

deployment

  : 애플리케이션 배포의 기본 단위가 되는 리소스, rs의 상위 리소스

simple-deployment.yaml

• deployment 리소스는 replicaSet 리소스를 관리한다.

• replicaSet의 리소스를 수정한다고 해서 revision이 변경되지는 않는다.

: 예로 replicas의 개수를 수정한다고 배포의 revision은 바뀌지 않으며, replicaSet만 변경된다.

• 컨테이너를 변경하고 재 배포하면, 기존 컨테이너는 중지되고 revision 이 2가 된다.

$ kubectl rollout history deployment health-check-app 

1) yaml 파일 정의해서 생성하기
$ kubectl apply -f simple-deployment.yaml --record

(명령 실행 기록을 남기는 --record 옵션)

2) deployment revision 확인

$ kubectl rollout history deployment health-check-app
$ kubectl rollout history deployment health-check-app --revision=1

3) rollback 하기

$ kubectl rollout undo deployment health-check-app
$ kubectl rollout undo deployment health-check-app  --revision=1

4) deployment  진행 상태 확인

$ kubectl rollout status deployment health-check-app

5) deployment 상세 확인

$ kubectl describe deployment health-check-app 

service

: po의 집합(주로 rs)에 대한 서비스 디스커버리를 제공하는 리소스
: service의 대상이 되는 pod는 label selector로 정해진다.

• service type 4가지가 존재함.
  cluster IP : cluster IP 생성

Node Port : cluster IP 생성 및 global port 개방
load Balancer : 로컬 환경에서는 사용 할 수 없음. 주로 클라우드 플랫폼에서 사용
external name : 셀렉터 및 포트 정의 하지 않음. externalName만으로 접근

simple-service.yaml

1) service 조회
$ kubectl get svc

ingress

service로 nodePort를 노출시킬 때, l4(tcp) 레벨까지만 다룰 수 있기 때문에 http/https 경로를 기반으로 서비스를 전환하는 l7 레벨의 제어는 불가능하다. 이를 해결하기 위한 리소스가 ingress이다.

로컬 환경에서는 인그레스를 사용해 서비스를 노출 시킬 수 없기 때문에 nginx_ingress_controller를 다음과 같이 배포해야 한다.

1) ingress-nginx의 배포

-namespace

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/mandatory.yaml

- service, pod

$kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/cloud-generic.yaml

2) ingress-nginx의 service와 pod 조회

$ kubectl -n ingress-nginx get svc, pod

3) simple-svc.yaml 생성 및 실행

$ kubectl apply -f simple-svc.yaml

4) simple-ingress.yaml 생성 및 실행

$ kubectl apply -f simple-ingress.yaml

5) 테스트

$  curl http://localhost/healthCheck -H 'Host: com.k8s.myapp' 

> 결과

배경

시대가 변함에 따라, 과거 모놀로틱 아키텍쳐의 많은 서비스를 거쳐 많은 프로젝트들이 MSA 기반의 트렌드로 변하고 있다.

이에 따라 애플리케이션들은 물리 서버 혹은 물리 서버의 VM(Virtual Machine)을 지나 도커와 같은 컨테이너 기반의 가상화 플랫폼위의 컨테이너에 존재하는 시대가 되었다.

Container Orchestration

컨테이너는 애플키에션을 포장하고 실행하며 관리하기에 좋은 도구이다. 하지만 컨테이너의 확장에 따라 이러한 컨테이너들의 관리해줄 도구가 분명 필요하다. 즉 간단하게 말해서 쿠버네티스는 컨테이너 관리 도구라고 생각하면 쉽다.

Apache Mesos, Docker Swarm, ECS 등 다양한 Container Orchestration이 존재하지만 확실하게 쿠버네티스는 높은 수준의 관리 기능을 제공해 주는 인기있는 툴이다.

Kubernetes

- 구글에서 15년간 프로덕션 워크로드 운영한 경험을 토대로 구축

- 컨테이너 운영을 자동화하기 위한 컨테이너 오케스트레이션 도구

- 약어 K8s ( k와 s 사이에 8글자라서.. 하하^^), Kube 등으로 불림

- 많은 수의 컨테이너를 협조적으로 연동하기 위한 통합 시스템

- 명령어 도구 kubectl 제공

- 러닝 커브가 좀 높다.

특징

1. Service Discovey
   : 쿠버네티스는 DNS 및 자체 IP를 사용하여 컨테이너를 노출한다.
2. load Balancing
    : 컨테이너의 트래픽이 많으면 로드밸런싱을 하여 배포한다.
3. Storage Orchestraion
   : 로컬 저장소 및 클라우드와 시스템과 연동 및 자동 탑재한다.
4. Self-Healing
   : 문제가 발생한 컨테이너를 자동 재시작한다.
5. Automated rollout and rollback
   : 컨테이너의 원하는 상태를 서술하며 언제든지 변경가능하다.
6. Batch execute
   : 스케쥴러 배치 작업이 가능하다. 
7. Horizontal Scaling
   : CPU 사용에 따라서, 명령어 혹은 UI 등과 함께 Scale Up and Down이 가능하다.
8. Docker Host Management

참고

 https://kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/

Maximum Connection

도커 버전 2.0.0.0-mac81 버전에서 테스트 도중 전체 컨테이너의 TCP Connection에 대해  제한이 있었다.

물론 도커 기본 메모리 같은 기타 자원에 의해 연결이 더 제한 될 사항은 있지만 기본적으로 테스트 해 본 결과 1970개의 제한이 있었다.

Library/Group Containers/group.com.docker/ 경로의 setting.json 파일을 통해 도커 기본 설정을 확인할 수 있는데,

vpnKitMaxConnections 키 값으로 connection 제한을 설정할 수 있다.

jedis는 사실상 java 기반 응용프로그램 표준 드라이버이고 많이 사용함에도 Spring에서 lettuce를 선호하는 점은 다음과 같다.

여러 쓰레드에서 단일 jedis 인스턴스를 공유하려 할때 jedis는 쓰레드에 안전하지 않다. 멀티쓰레드환경에서 고려해야할 상황이 따른다.

안전한 방법은 pooling(Thread-pool)과 같은 jedis-pool을 사용하는 것이지만 물리적인 비용의(connection할 인스턴스를 미리 만들어놓고 대기하는 연결비용의 증가) 증가가 따른다.

반면 lettuce는 netty 라이브러리 위에서 구축되었고, connection 인스턴스((StatefulRedisConnection))를 여러 쓰레드에서 공유가 가능하다.(Thread-safe)

=> 혼동할 수 있는데, connection 인스턴스의 공유라는 점에서 Thread-safe를 논점을 둔 점이고 Single-Thread의 레디스에 데이터에 접근할 때는 또다르게 고려해야 할 점이다.

https://github.com/spring-projects/spring-session/issues/789

자바 기준  사람들이 많이 사용하는 Redis Library는 다음과 같다.

• Jedis
• Lettuce
• Redisson

...

기타 라이브러리는 아래에서 확인 가능하다.

https://redis.io/clients#java

Jedis 

- Jedis의 가장 큰 장점은 사용하기 쉽다.

https://github.com/xetorthio/jedis

Lettuce

- 쓰레드로부터 안전한 sync 그리고 async와 reactive(Concurrent API structed Observer Pattern) 사용을 위한 클라이언트

- 또한 코덱과 파이프라인 등 고급 설정을 지원한다.

- netty 기반 라이브러리

- JAVA8 이상에서 안정화

https://github.com/lettuce-io/lettuce-core

Redisson

- Jedis나 Lettuce에 비해 사용하기 까다롭다.

- redis 명령어와 같은 low-level 메소드를 제공한다.

- 기타 자세한 특징

: http://redisgate.kr/redis/clients/redisson_intro.php

https://github.com/redisson/redisson

Spring Data Redis  in Spring boot

- Redis를 마치 jpa repository를 이용하듯 인터페이스를 제공하는 스프링 모듈

- crudRepository를 지원하기 때문에 직관적이다. 

- Jedis, lettuce만 공식 지원,  Redisson은 현재 포함되지 않는다.

=> 주관적인 견해로 라이브러리를 선택할 때, 라이브러리 관리가 제대로 잘되고 있는지 그리고 내가 어떤 목적으로 쓸지가 중요한 것 같다.