안녕하세요.

https://computingforgeeks.com/run-teleport-in-docker-docker-compose/

https://github.com/gravitational/teleport#docker

https://gallery.ecr.aws/gravitational/teleport

TELEPORT_DOCKER_IMAGE=public.ecr.aws/gravitational/teleport:12

mkdir -p ~/teleport/{config,data}

TELEPORT_HOSTNAME=" teleport.example.com"

###아래의 Docker run은 실제 Docker를 실행하는게 아니고 설정파일을 만드는과정으로 빠지면 안됨
docker run --hostname ${TELEPORT_HOSTNAME} --rm \
  --entrypoint=/bin/sh \
  -v ~/teleport/config:/etc/teleport \
  ${TELEPORT_DOCKER_IMAGE} -c "teleport configure > /etc/teleport/teleport.yaml"


[root@ip-10-32-1-156 teleport]# cat docker-compose.yaml
version: '3.7'
services:
  teleport:
    image: "quay.io/gravitational/teleport:12.2.5-amd64"
    container_name: teleport
    restart: always
    hostname: "teleport.sabo.sbx.infograb.io"
    volumes:
      - ./config:/etc/teleport
      - ./data:/var/lib/teleport
    ports:
      - 3023:3023
      - 3024:3024
      - 3025:2025
      - 3080:3080
      


$ docker exec teleport tctl users add admin --roles=editor,access --logins=root,ubuntu,ec2-user

그리고 webpage.co.kr:3080 접속하면 계정 생성 페이지로 접속된다.

이후 MFA 설정 하고 로그인하면 된다.

위와같이 기본적으로 localhost 연결이 가능하고 이외에 애플리케이션, 대시보드등 접근이 가능하다.

위와같이 web 브라우져에서 바로 접속이 가능하다.(인터넷만 되는 환경에서 급한 작업 있을때 유용할듯 ?)

일단 애플리케이션(웹페이지)로의 접근은 필요성이 있을것같은데 서버 관리에 필요한 ssh 접근은 흠... 세션 레코딩 기능이 참 매력적이긴 한데...

일단 세션 레코딩만해도 큰 메리트가 있으니까 일단 접속해보자.

macos는 brew install teleport 명령어로 teleport 설치하고 tsh 명령어로 접근이 가능하다.
근데
The Teleport package in Homebrew is not maintained by Teleport and we can't guarantee its reliability or security. We recommend the use of our own Teleport packages.
라고 하니 

https://goteleport.com/download/?os=mac 에서 직접 설치해주자.

Download the MacOS .pkg installer (tsh client only, signed) and double-click to run it.

4주차는 EKS observability 이다.

시작.

로깅 대상은 컨트롤 플레인, node, 애플리케이션이 있다.

먼저 컨트롤 플레인 로깅이다.

현재 모든 로깅은 꺼져있는 상태

위와같이 enable 해주면

On 확인

# EC2 Instance가 NodeNotReady 상태인 로그 검색
fields @timestamp, @message
| filter @message like /**NodeNotReady**/
| sort @timestamp desc

# kube-apiserver-audit 로그에서 userAgent 정렬해서 아래 4개 필드 정보 검색
fields userAgent, requestURI, @timestamp, @message
| filter @logStream ~= "kube-apiserver-audit"
| stats count(userAgent) as count by userAgent
| sort count desc

#
fields @timestamp, @message
| filter @logStream ~= "**kube-scheduler**"
| sort @timestamp desc

#
fields @timestamp, @message
| filter @logStream ~= "**authenticator**"
| sort @timestamp desc

#
fields @timestamp, @message
| filter @logStream ~= "kube-controller-manager"
| sort @timestamp desc

log insights 에서 필터링하여 로그를 확인할수 있다.

위와같이 프로메테우스 메트릭 형태로도 볼수있다.

그외에도 아래 내용을 참고하여 컨트롤플래인단 로그를 확인할수 있다.

# How to monitor etcd database size? >> 아래 10.0.X.Y IP는 어디일까요? >> 아래 주소로 프로메테우스 메트릭 수집 endpoint 주소로 사용 가능한지???
**kubectl get --raw /metrics | grep "etcd_db_total_size_in_bytes"**
etcd_db_total_size_in_bytes{endpoint="<http://10.0.160.16:2379>"} 4.665344e+06
etcd_db_total_size_in_bytes{endpoint="<http://10.0.32.16:2379>"} 4.636672e+06
etcd_db_total_size_in_bytes{endpoint="<http://10.0.96.16:2379>"} 4.640768e+06

**kubectl get --raw=/metrics | grep apiserver_storage_objects |awk '$2>100' |sort -g -k 2**

# CW Logs Insights 쿼리
fields @timestamp, @message, @logStream
| filter @logStream like /**kube-apiserver-audit**/
| filter @message like /**mvcc: database space exceeded**/
| limit 10

# How do I identify what is consuming etcd database space?
**kubectl get --raw=/metrics | grep apiserver_storage_objects |awk '$2>100' |sort -g -k 2**
**kubectl get --raw=/metrics | grep apiserver_storage_objects |awk '$2>50' |sort -g -k 2**
apiserver_storage_objects{resource="clusterrolebindings.rbac.authorization.k8s.io"} 78
apiserver_storage_objects{resource="clusterroles.rbac.authorization.k8s.io"} 92

# CW Logs Insights 쿼리 : Request volume - Requests by User Agent:
fields userAgent, requestURI, @timestamp, @message
| filter @logStream like /**kube-apiserver-audit**/
| stats count(*) as count by userAgent
| sort count desc

# CW Logs Insights 쿼리 : Request volume - Requests by Universal Resource Identifier (URI)/Verb:
filter @logStream like /**kube-apiserver-audit**/
| stats count(*) as count by requestURI, verb, user.username
| sort count desc

# Object revision updates
fields requestURI
| filter @logStream like /**kube-apiserver-audit**/
| filter requestURI like /pods/
| filter verb like /patch/
| filter count > 8
| stats count(*) as count by requestURI, responseStatus.code
| filter responseStatus.code not like /500/
| sort count desc

#
fields @timestamp, userAgent, responseStatus.code, requestURI
| filter @logStream like /**kube-apiserver-audit**/
| filter requestURI like /pods/
| filter verb like /patch/
| filter requestURI like /name_of_the_pod_that_is_updating_fast/
| sort @timestamp

이번엔 컨테이너 로깅이다..

# NGINX 웹서버 **배포**
helm repo add bitnami <https://charts.bitnami.com/bitnami>

# 사용 리전의 인증서 ARN 확인
CERT_ARN=$(aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn[]' --output text)
echo $CERT_ARN

# 도메인 확인
echo $MyDomain

# 파라미터 파일 생성
cat < nginx-values.yaml
service:
    type: NodePort

ingress:
  enabled: true
  ingressClassName: alb
  hostname: nginx.$MyDomain
  path: /*
  annotations: 
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
    alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
    alb.ingress.kubernetes.io/success-codes: 200-399
    **alb.ingress.kubernetes.io/load-balancer-name: $CLUSTER_NAME-ingress-alb
    alb.ingress.kubernetes.io/group.name: study
    alb.ingress.kubernetes.io/ssl-redirect: '443'**
EOT
cat nginx-values.yaml | yh

# 배포
**helm install nginx bitnami/nginx --version 14.1.0 -f nginx-values.yaml**

# 확인
kubectl get ingress,deploy,svc,ep nginx
kubectl get targetgroupbindings # ALB TG 확인

# 접속 주소 확인 및 접속
echo -e "Nginx WebServer URL = "
curl -s 
kubectl logs deploy/nginx -f

# 반복 접속
while true; do curl -s  -I | head -n 1; date; sleep 1; done

# (참고) 삭제 시
helm uninstall nginx

위와같이 진행한다. 다만 ACM 은 인증서 따로 추가해줘야 한다.

CERT_ARN=$(aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn[]' --output text) echo $CERT_ARN
이부분

위와같이 배포 완료

컨테이너도 위와같이 로깅을 확인할수있다.

이번에는 외부에서 로그를 수집하도록 하는 방법이다.

# 설치
FluentBitHttpServer='On'
FluentBitHttpPort='2020'
FluentBitReadFromHead='Off'
FluentBitReadFromTail='On'
**curl -s <https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/quickstart/cwagent-fluent-bit-quickstart.yaml> | sed 's/{{cluster_name}}/'${CLUSTER_NAME}'/;s/{{region_name}}/'${AWS_DEFAULT_REGION}'/;s/{{http_server_toggle}}/"'${FluentBitHttpServer}'"/;s/{{http_server_port}}/"'${FluentBitHttpPort}'"/;s/{{read_from_head}}/"'${FluentBitReadFromHead}'"/;s/{{read_from_tail}}/"'${FluentBitReadFromTail}'"/' | kubectl apply -f -**

# 설치 확인
kubectl get-all -n amazon-cloudwatch
kubectl get ds,pod,cm,sa -n amazon-cloudwatch
kubectl describe **clusterrole cloudwatch-agent-role fluent-bit-role**                          # 클러스터롤 확인
kubectl describe **clusterrolebindings cloudwatch-agent-role-binding fluent-bit-role-binding**  # 클러스터롤 바인딩 확인
kubectl -n amazon-cloudwatch logs -l name=cloudwatch-agent -f # 파드 로그 확인
kubectl -n amazon-cloudwatch logs -l k8s-app=fluent-bit -f    # 파드 로그 확인
for node in $N1 $N2 $N3; do echo ">>>>> $node <<<<<"; ssh ec2-user@$node sudo ss -tnlp | grep fluent-bit; echo; done

# cloudwatch-agent 설정 확인
**kubectl describe cm cwagentconfig -n amazon-cloudwatch**
{
  "agent": {
    "region": "ap-northeast-2"
  },
  "logs": {
    "metrics_collected": {
      "kubernetes": {
        "cluster_name": "myeks",
        "metrics_collection_interval": 60
      }
    },
    "force_flush_interval": 5
  }
}

# CW 파드가 수집하는 방법 : Volumes에 HostPath를 살펴보자! >> / 호스트 패스 공유??? 보안상 안전한가? 좀 더 범위를 좁힐수는 없을까요?
**kubectl describe -n amazon-cloudwatch ds cloudwatch-agent**
...
ssh ec2-user@$N1 sudo tree /dev/disk
...

# Fluent Bit Cluster Info 확인
**kubectl get cm -n amazon-cloudwatch fluent-bit-cluster-info -o yaml | yh**
apiVersion: v1
data:
  cluster.name: myeks
  http.port: "2020"
  http.server: "On"
  logs.region: ap-northeast-2
  read.head: "Off"
  read.tail: "On"
kind: ConfigMap
...

# Fluent Bit 로그 INPUT/FILTER/OUTPUT 설정 확인 - [링크](<https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs-FluentBit.html#ContainerInsights-fluentbit-multiline>)
## 설정 부분 구성 : application-log.conf , dataplane-log.conf , fluent-bit.conf , host-log.conf , parsers.conf
**kubectl describe cm fluent-bit-config -n amazon-cloudwatch
...
application-log.conf**:
----
[**INPUT**]
    Name                tail
    Tag                 **application.***
    Exclude_Path        /var/log/containers/cloudwatch-agent*, /var/log/containers/fluent-bit*, /var/log/containers/aws-node*, /var/log/containers/kube-proxy*
    **Path                /var/log/containers/*.log**
    multiline.parser    docker, cri
    DB                  /var/fluent-bit/state/flb_container.db
    Mem_Buf_Limit       50MB
    Skip_Long_Lines     On
    Refresh_Interval    10
    Rotate_Wait         30
    storage.type        filesystem
    Read_from_Head      ${READ_FROM_HEAD}

[**FILTER**]
    Name                kubernetes
    Match               application.*
    Kube_URL            <https://kubernetes.default.svc:443>
    Kube_Tag_Prefix     application.var.log.containers.
    Merge_Log           On
    Merge_Log_Key       log_processed
    K8S-Logging.Parser  On
    K8S-Logging.Exclude Off
    Labels              Off
    Annotations         Off
    Use_Kubelet         On
    Kubelet_Port        10250
    Buffer_Size         0

[**OUTPUT**]
    Name                cloudwatch_logs
    Match               application.*
    region              ${AWS_REGION}
    **log_group_name      /aws/containerinsights/${CLUSTER_NAME}/application**
    log_stream_prefix   ${HOST_NAME}-
    auto_create_group   true
    extra_user_agent    container-insights
**...**

# Fluent Bit 파드가 수집하는 방법 : Volumes에 HostPath를 살펴보자!
**kubectl describe -n amazon-cloudwatch ds fluent-bit**
...
ssh ec2-user@$N1 sudo tree /var/log
...

# (참고) 삭제
curl -s <https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/quickstart/cwagent-fluent-bit-quickstart.yaml> | sed 's/{{cluster_name}}/'${CLUSTER_NAME}'/;s/{{region_name}}/'${AWS_DEFAULT_REGION}'/;s/{{http_server_toggle}}/"'${FluentBitHttpServer}'"/;s/{{http_server_port}}/"'${FluentBitHttpPort}'"/;s/{{read_from_head}}/"'${FluentBitReadFromHead}'"/;s/{{read_from_tail}}/"'${FluentBitReadFromTail}'"/' | kubectl delete -f -

우선 위와같이 설치를 진행한다.  

정상적으로 설치 완료

위와같이 fluent bit로 어떻게 가공 과정을 볼수있다.

콘솔에서도 로그 확인

Insights 항목에서도 여러 항목 모니터링 가능

이번에는 모니터링을하기위한 메트릭수집 도구들을 알아볼것이다.

# 배포
**kubectl apply -f <https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml**>

# 메트릭 서버 확인 : 메트릭은 15초 간격으로 cAdvisor를 통하여 가져옴
kubectl get pod -n kube-system -l k8s-app=metrics-server
kubectl api-resources | grep metrics
kubectl get apiservices |egrep '(AVAILABLE|metrics)'

# 노드 메트릭 확인
kubectl top node

# 파드 메트릭 확인
kubectl top pod -A
kubectl top pod -n kube-system --sort-by='cpu'
kubectl top pod -n kube-system --sort-by='memory'

메트릭서버 설치방법(만 알아본다.)

kwatch라는것도 있다. 이걸로 slack 웹훅을 걸어줄수있다.

# configmap 생성
cat < ~/kwatch-config.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: kwatch
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: kwatch
  namespace: kwatch
data:
  config.yaml: |
    **alert**:
      **slack**:
        webhook: '**<https://hooks.slack.com/services/T03G23CRBNZ/sssss/sss**>'
        title: $NICK-EKS
        #text:
    **pvcMonitor**:
      enabled: true
      interval: 5
      threshold: 70
EOT
**kubectl apply -f kwatch-config.yaml**

# 배포
kubectl apply -f <https://raw.githubusercontent.com/abahmed/kwatch/v0.8.3/deploy/**deploy.yaml**>

botube라는 도구도 있다.

# repo 추가
helm repo add botkube <https://charts.botkube.io>
helm repo update

# 변수 지정
export ALLOW_KUBECTL=true
export ALLOW_HELM=true
export SLACK_CHANNEL_NAME=webhook3

#
cat < botkube-values.yaml
actions:
  'describe-created-resource': # kubectl describe
    enabled: true
  'show-logs-on-error': # kubectl logs
    enabled: true

executors:
  k8s-default-tools:
    botkube/helm:
      enabled: true
    botkube/kubectl:
      enabled: true
EOT

# 설치
helm install --version **v1.0.0** botkube --namespace botkube --create-namespace \\
--set communications.default-group.socketSlack.enabled=true \\
--set communications.default-group.socketSlack.channels.default.name=${SLACK_CHANNEL_NAME} \\
--set communications.default-group.socketSlack.appToken=${SLACK_API_APP_TOKEN} \\
--set communications.default-group.socketSlack.botToken=${SLACK_API_BOT_TOKEN} \\
--set settings.clusterName=${CLUSTER_NAME} \\
--set 'executors.k8s-default-tools.botkube/kubectl.enabled'=${ALLOW_KUBECTL} \\
--set 'executors.k8s-default-tools.botkube/helm.enabled'=${ALLOW_HELM} \\
-f **botkube-values.yaml** botkube/botkube

# 참고 : 삭제 시
helm uninstall botkube --namespace botkube

# 연결 상태, notifications 상태 확인
**@Botkube** ping
**@Botkube** status notifications

# 파드 정보 조회
**@Botkube** k get pod
**@Botkube** kc get pod --namespace kube-system
**@Botkube** kubectl get pod --namespace kube-system -o wide

# Actionable notifications
**@Botkube** kubectl

botkube의 장점은 슬랙과 연동하여 @Botkube로 슬랙의 지정채널에서 파드의 정보를 불러오는등 슬랙에서 클러스터 정보 확인이 가능한장점이 있다. 

자 이제 마지막으로 프로메테우스&그라파나이다.

프로메테우스 오퍼레이터 : 프로메테우스 및 프로메테우스 오퍼레이터를 이용하여 메트릭 수집과 알람 기능 실습
https://malwareanalysis.tistory.com/566

Thanos 타노드 : 프로메테우스 확장성과 고가용성 제공
https://hanhorang31.github.io/post/pkos2-4-monitoring/

프로메테우스란

제공 기능

• a multi-dimensional data model with time series data(=TSDB, 시계열 데이터베이스) identified by metric name and key/value pairs
• PromQL, a flexible query language to leverage this dimensionality
• no reliance on distributed storage; single server nodes are autonomous
• time series collection happens via a pull model over HTTP
• pushing time series is supported via an intermediary gateway
• targets are discovered via service discovery or static configuration
• multiple modes of graphing and dashboarding support

설치 방법은 아래와 같다.

# 모니터링
kubectl create ns monitoring
watch kubectl get pod,pvc,svc,ingress -n monitoring

# 사용 리전의 인증서 ARN 확인
CERT_ARN=`aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn[]' --output text`
echo $CERT_ARN

****# repo 추가
helm repo add prometheus-community <https://prometheus-community.github.io/helm-charts>

# 파라미터 파일 생성
cat < monitor-values.yaml
**prometheus**:
  prometheusSpec:
    podMonitorSelectorNilUsesHelmValues: false
    serviceMonitorSelectorNilUsesHelmValues: false
    retention: 5d
    retentionSize: "10GiB"

  ingress:
    enabled: true
    ingressClassName: alb
    hosts: 
      - prometheus.$MyDomain
    paths: 
      - /*
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/success-codes: 200-399
      **alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
      alb.ingress.kubernetes.io/group.name: study
      alb.ingress.kubernetes.io/ssl-redirect: '443'**

**grafana**:
  defaultDashboardsTimezone: Asia/Seoul
  adminPassword: prom-operator

  ingress:
    enabled: true
    ingressClassName: alb
    hosts: 
      - grafana.$MyDomain
    paths: 
      - /*
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/success-codes: 200-399
      **alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
      alb.ingress.kubernetes.io/group.name: study
      alb.ingress.kubernetes.io/ssl-redirect: '443'**

defaultRules:
  create: false
**kubeControllerManager:
  enabled: false
kubeEtcd:
  enabled: false
kubeScheduler:
  enabled: false**
alertmanager:
  enabled: false

# alertmanager:
#   ingress:
#     enabled: true
#     ingressClassName: alb
#     hosts: 
#       - alertmanager.$MyDomain
#     paths: 
#       - /*
#     annotations:
#       alb.ingress.kubernetes.io/scheme: internet-facing
#       alb.ingress.kubernetes.io/target-type: ip
#       alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
#       alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
#       alb.ingress.kubernetes.io/success-codes: 200-399
#       alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
#       alb.ingress.kubernetes.io/group.name: study
#       alb.ingress.kubernetes.io/ssl-redirect: '443'
EOT
cat monitor-values.yaml | yh

# 배포
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack --version **45.**27.2 \\
--**set** prometheus.prometheusSpec.scrapeInterval='15s' --**set** prometheus.prometheusSpec.evaluationInterval='15s' \\
-f **monitor-values.yaml** --namespace monitoring

# 확인
~~## alertmanager-0 : 사전에 정의한 정책 기반(예: 노드 다운, 파드 Pending 등)으로 시스템 경고 메시지를 생성 후 경보 채널(슬랙 등)로 전송~~
## grafana : 프로메테우스는 메트릭 정보를 저장하는 용도로 사용하며, 그라파나로 시각화 처리
## prometheus-0 : 모니터링 대상이 되는 파드는 ‘exporter’라는 별도의 사이드카 형식의 파드에서 모니터링 메트릭을 노출, pull 방식으로 가져와 내부의 시계열 데이터베이스에 저장
## node-exporter : 노드익스포터는 물리 노드에 대한 자원 사용량(네트워크, 스토리지 등 전체) 정보를 메트릭 형태로 변경하여 노출
## operator : 시스템 경고 메시지 정책(prometheus rule), 애플리케이션 모니터링 대상 추가 등의 작업을 편리하게 할수 있게 CRD 지원
## kube-state-metrics : 쿠버네티스의 클러스터의 상태(kube-state)를 메트릭으로 변환하는 파드
helm list -n monitoring
kubectl get pod,svc,ingress -n monitoring
kubectl get-all -n monitoring
**kubectl get prometheus,servicemonitors -n monitoring**
~~~~**kubectl get crd | grep monitoring**

위와같이 설치 완료

프로메테우스 메트릭 수집정보를 확인해보자.

노드의 정보를 가져오는 노드 익스포터라는 파드가 올라온것을 확인할수있다.

위 메트릭들을 수집한다.

프로메테우스가 수집할 타겟들

아까 봤떤 노드 익스포터

그라파나 확인

다른 사용자가 만들어둔 여러가지 대시보드들이 있다.

공식 대시보드 가져오기 - 링크 추천

• [Kubernetes / Views / Global] Dashboard → New → Import → 15757 입력 후 Load ⇒ 데이터소스(Prometheus 선택) 후 Import 클릭
• [1 Kubernetes All-in-one Cluster Monitoring KR] Dashboard → New → Import → 13770 or 17900 입력 후 Load ⇒ 데이터소스(Prometheus 선택) 후 Import 클릭
• [Node Exporter Full] Dashboard → New → Import → 1860 입력 후 Load ⇒ 데이터소스(Prometheus 선택) 후 Import 클릭
• kube-state-metrics-v2 가져와보자 : Dashboard ID copied! (13332) 클릭 - 링크
  • [kube-state-metrics-v2] Dashboard → New → Import → 13332 입력 후 Load ⇒ 데이터소스(Prometheus 선택) 후 Import 클릭
• [Amazon EKS] **AWS CNI Metrics 16032 - 링크

위 항목에서 Dashboard 임폴트가 가능하다.

임폴트한 대시보드 화면

그럼 마지막으로 아까 배포한 Nginx 파드의 여러가지 정보를 모니터링해보자.

# 모니터링
watch -d kubectl get pod

# 파라미터 파일 생성 : 서비스 모니터 방식으로 nginx 모니터링 대상을 등록하고, export 는 9113 포트 사용, nginx 웹서버 노출은 AWS CLB 기본 사용
cat <<EOT > ~/nginx_metric-values.yaml
metrics:
  enabled: true

  service:
    port: 9113

  serviceMonitor:
    enabled: true
    namespace: monitoring
    interval: 10s
EOT

# 배포
helm **upgrade** nginx bitnami/nginx **--reuse-values** -f nginx_metric-values.yaml

# 확인
kubectl get pod,svc,ep
kubectl get servicemonitor -n monitoring nginx
kubectl get servicemonitor -n monitoring nginx -o json | jq

# 메트릭 확인 >> 프로메테우스에서 Target 확인
NGINXIP=$(kubectl get pod -l app.kubernetes.io/instance=nginx -o jsonpath={.items[0].status.podIP})
curl -s <http://$NGINXIP:9113/metrics> # nginx_connections_active Y 값 확인해보기
curl -s <http://$NGINXIP:9113/metrics> | grep ^nginx_connections_active

# nginx 파드내에 컨테이너 갯수 확인
kubectl get pod -l app.kubernetes.io/instance=nginx
kubectl describe pod -l app.kubernetes.io/instance=nginx

# 접속 주소 확인 및 접속
echo -e "Nginx WebServer URL = <https://nginx.$MyDomain>"
curl -s <https://nginx.$MyDomain>
kubectl logs deploy/nginx -f

# 반복 접속
while true; do curl -s <https://nginx.$MyDomain> -I | head -n 1; date; sleep 1; done

추가 참고.

kubecost - k8s 리소스별 비용 현황 가시화 도구

# 
cat < cost-values.yaml
global:
  grafana:
    enabled: true
    proxy: false

priority:
  enabled: false
networkPolicy:
  enabled: false
podSecurityPolicy:
  enabled: false

persistentVolume:
    storageClass: "gp3"

prometheus:
  kube-state-metrics:
    disabled: false
  nodeExporter:
    enabled: true

reporting:
  productAnalytics: true
EOT

**# kubecost chart 에 프로메테우스가 포함되어 있으니, 기존 프로메테우스-스택은 삭제하자 : node-export 포트 충돌 발생**
**helm uninstall -n monitoring kube-prometheus-stack**

# 배포
kubectl create ns kubecost
helm install kubecost oci://public.ecr.aws/kubecost/cost-analyzer --version **1.103.2** --namespace kubecost -f cost-values.yaml

# 배포 확인
kubectl get-all -n kubecost
kubectl get all -n kubecost

# kubecost-cost-analyzer 파드 IP변수 지정 및 접속 확인
CAIP=$(kubectl get pod -n kubecost -l app=cost-analyzer -o jsonpath={.items[0].status.podIP})
curl -s $CAIP:9090

# 외부에서 bastion EC2 접속하여 특정 파드 접속 방법 : socat(SOcket CAT) 활용 - [링크](<https://www.redhat.com/sysadmin/getting-started-socat>)
yum -y install socat
socat TCP-LISTEN:80,fork TCP:$CAIP:9090
웹 브라우저에서 bastion EC2 IP로 접속

설치 방법

위와같이 kubecost를 통해 리소스별 비용 확인이 가능하다.

오픈텔레메트리

https://opentelemetry.io/docs/what-is-opentelemetry/ 참고

3주차 eks 스터디는 스토리지 및 노드 관리이다.

3주차 실습 환경 구성은 앞선 2주차와 마찬가지로 클라우드 포메이션을 통해 배포를 진행한다.

2주차

https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/eks-oneclick.yaml

3주차

https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/eks-oneclick2.yaml

2주차 3주차 각각 다운받아서 diff로 비교해보면 efs 쪽 설정이 추가된것을 확인할수있다.

• Amazon EKS 윈클릭 배포 (EFS 생성 추가) & 기본 설정
  • 기본 설정 및 EFS 확인

  # default 네임스페이스 적용
  **kubectl ns default**
  
  # (옵션) context 이름 변경
  NICK=<각자 자신의 닉네임>
  **NICK=gasida**
  kubectl ctx
  kubectl config rename-context admin@myeks.ap-northeast-2.eksctl.io **$NICK@myeks**
  
  # EFS 확인 : AWS 관리콘솔 EFS 확인해보자
  mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport ***<자신의 EFS FS ID>***.efs.ap-northeast-2.amazonaws.com:/ **/mnt/myefs**
  **df -hT --type nfs4**
  mount | grep nfs4
  **echo "efs file test" > /mnt/myefs/memo.txt**
  cat /mnt/myefs/memo.txt
  **rm -f /mnt/myefs/memo.txt**
  
  # 스토리지클래스 및 CSI 노드 확인
  kubectl get sc
  kubectl get sc gp2 -o yaml | yh
  kubectl get csinodes
  
  # 노드 정보 확인
  kubectl get node --label-columns=node.kubernetes.io/instance-type,eks.amazonaws.com/capacityType,topology.kubernetes.io/zone
  ****eksctl get iamidentitymapping --cluster myeks
  ****
  # 노드 IP 확인 및 PrivateIP 변수 지정
  N1=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2a -o jsonpath={.items[0].status.addresses[0].address})
  N2=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2b -o jsonpath={.items[0].status.addresses[0].address})
  N3=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2c -o jsonpath={.items[0].status.addresses[0].address})
  echo "export N1=$N1" >> /etc/profile
  echo "export N2=$N2" >> /etc/profile
  echo "export N3=$N3" >> /etc/profile
  echo $N1, $N2, $N3
  
  # 노드 보안그룹 ID 확인
  NGSGID=$(aws ec2 describe-security-groups --filters Name=group-name,Values=*ng1* --query "SecurityGroups[*].[GroupId]" --output text)
  aws ec2 authorize-security-group-ingress --group-id $NGSGID --protocol '-1' --cidr 192.168.1.100/32
  
  # 워커 노드 SSH 접속
  ssh ec2-user@$N1 hostname
  ssh ec2-user@$N2 hostname
  ssh ec2-user@$N3 hostname
  
  # 노드에 툴 설치
  ssh ec2-user@$N1 sudo yum install links tree jq tcpdump sysstat -y
  ssh ec2-user@$N2 sudo yum install links tree jq tcpdump sysstat -y
  ssh ec2-user@$N3 sudo yum install links tree jq tcpdump sysstat -y
  

  • AWS LB/ExternalDNS, kube-ops-view 설치

  # AWS LB Controller
  helm repo add eks <https://aws.github.io/eks-charts>
  helm repo update
  helm install aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=$CLUSTER_NAME \\
    --set serviceAccount.create=false --set serviceAccount.name=aws-load-balancer-controller
  
  # ExternalDNS
  MyDomain=<자신의 도메인>
  **MyDomain=gasida.link**
  MyDnzHostedZoneId=$(aws route53 list-hosted-zones-by-name --dns-name "${MyDomain}." --query "HostedZones[0].Id" --output text)
  echo $MyDomain, $MyDnzHostedZoneId
  curl -s -O <https://raw.githubusercontent.com/gasida/PKOS/main/aews/externaldns.yaml>
  MyDomain=$MyDomain MyDnzHostedZoneId=$MyDnzHostedZoneId envsubst < externaldns.yaml | kubectl apply -f -
  
  # kube-ops-view
  helm repo add geek-cookbook <https://geek-cookbook.github.io/charts/>
  helm install kube-ops-view geek-cookbook/kube-ops-view --version 1.2.2 --set env.TZ="Asia/Seoul" --namespace kube-system
  kubectl patch svc -n kube-system kube-ops-view -p '{"spec":{"type":"LoadBalancer"}}'
  kubectl **annotate** service kube-ops-view -n kube-system "external-dns.alpha.kubernetes.io/hostname=**kubeopsview**.$MyDomain"
  echo -e "Kube Ops View URL = http://**kubeopsview**.$MyDomain:8080/#scale=1.5"
  

  • 설치 정보 확인

  # 이미지 정보 확인
  **kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" | tr -s '[[:space:]]' '\\n' | sort | uniq -c**
  
  # eksctl 설치/업데이트 addon 확인
  **eksctl get addon --cluster $CLUSTER_NAME**
  
  # IRSA 확인
  **eksctl get iamserviceaccount --cluster $CLUSTER_NAME**
  

2주차와 마찬가지(efs 및 2주차에서 실습 진행했떤 ALB등은 추가돼있음)로 위와같이 진행하면 3주차 실습 준비 완료

첫번째 사진처럼 파드안의 컨테이너 내 tmpFS가 있는경우 컨테이너가 종료되면 tmpFS내 데이터도 삭제된다.

마찬가지로 두번째 사진처럼 파드내에 볼륨이 있고 두개의 컨테이너가 해당 볼륨을 공유해서 사용하여도 파드가 종료되면 볼륨내 데이터도 삭제가 된다.

따라서 컨테이너, 파드의 종료여부와 상관없이 데이터를 보존하기 위해 PV/PVC가 필요하다.

앞서 PV/PVC를 이용하지 않는다면(즉 컨테이너 내에 임시의 파일시스템을 이용한다면)데이터가 보존되지 않는다고했는데 이를 실제로 확인해보면 아래와 같다.

10초간격으로 date를 찍는 busybox를 deployment로 배포하고 pod-out.txt 확인하면 10초에 한번씩 찍힌것을 볼수있다.

이후 busybox 파드를 종료후 다시 확인해보면 이전에 찍혔던 date(즉 기존 데이터)는 보존되지 않은것을 확인할수있다.

이번에는 local-path-provisioner 스트리지 클래스를 사용하여 데이터 보존성을 확인해보자.

위와같이 local-path-provisioner 사용하기 위해 localpth claim 을 생성해주고

위와같이 앞서 생성한 PVC를 마운트하여 파드를 실행하고 아까와같이 파드를 재시작하여 데이터 보존유무를 확인해보자.

위와같이 파드를 종료하여도 데이터가 없어지지않고 기존 데이터가 보존되는것을 확인할수있다.

실제 데이터는 node1에 저장돼있는것을 확인할수있다.

여기까지 eks 클러스터내의 파드를 이용한 볼륨 마운트를 알아보았는데 지금부터는 AWS EBS 마운트를 알아보도록 하자.

```bash
# 아래는 **aws-ebs-csi-driver** 전체 버전 정보와 기본 설치 버전(True) 정보 확인
**aws eks describe-addon-versions \\
    --addon-name aws-ebs-csi-driver \\
    --kubernetes-version 1.24 \\
    --query "addons[].addonVersions[].[addonVersion, compatibilities[].defaultVersion]" \\
    --output text**
v1.18.0-eksbuild.1
Tru
v1.17.0-eksbuild.1
False
...

# ISRA 설정 : AWS관리형 정책 AmazonEBSCSIDriverPolicy 사용
eksctl create **iamserviceaccount** \\
  --name **ebs-csi-controller-sa** \\
  --namespace kube-system \\
  --cluster ${CLUSTER_NAME} \\
  --attach-policy-arn arn:aws:iam::aws:policy/service-role/**AmazonEBSCSIDriverPolicy** \\
  --approve \\
  --role-only \\
  --role-name **AmazonEKS_EBS_CSI_DriverRole**

# ISRA 확인
kubectl get sa -n kube-system ebs-csi-controller-sa -o yaml | head -5
**eksctl get iamserviceaccount --cluster myeks**
NAMESPACE	    NAME				            ROLE ARN
kube-system 	ebs-csi-controller-sa		**arn:aws:iam::911283464785:role/AmazonEKS_EBS_CSI_DriverRole**
...

# Amazon EBS CSI driver addon 추가
eksctl create **addon** --name aws-ebs-csi-driver --cluster ${CLUSTER_NAME} --service-account-role-arn arn:aws:iam::${ACCOUNT_ID}:role/**AmazonEKS_EBS_CSI_DriverRole** --force

# 확인
**eksctl get addon --cluster ${CLUSTER_NAME}**
kubectl get deploy,ds -l=app.kubernetes.io/name=aws-ebs-csi-driver -n kube-system
kubectl get pod -n kube-system -l 'app in (ebs-csi-controller,ebs-csi-node)'
kubectl get pod -n kube-system -l app.kubernetes.io/component=csi-driver

# ebs-csi-controller 파드에 6개 컨테이너 확인
**kubectl get pod -n kube-system -l app=ebs-csi-controller -o jsonpath='{.items[0].spec.containers[*].name}' ; echo**
ebs-plugin csi-provisioner csi-attacher csi-snapshotter csi-resizer liveness-probe

# csinodes 확인
kubectl get csinodes

# gp3 스토리지 클래스 생성
kubectl get sc
cat <<EOT > gp3-sc.yaml
kind: **StorageClass**
apiVersion: storage.k8s.io/v1
metadata:
  name: gp3
**allowVolumeExpansion: true**
**provisioner: ebs.csi.aws.com**
volumeBindingMode: WaitForFirstConsumer
parameters:
  **type: gp3**
  allowAutoIOPSPerGBIncrease: 'true'
  encrypted: 'true'
  #fsType: ext4 # 기본값이 ext4 이며 xfs 등 변경 가능 >> 단 스냅샷 경우 ext4를 기본으로하여 동작하여 xfs 사용 시 문제가 될 수 있음 - 테스트해보자
EOT
**kubectl apply -f gp3-sc.yaml**
kubectl get sc
kubectl describe sc gp3 | grep Parameters
```

-

2주차때 했던것처럼 IRSA 설정해서 AWS EBS와 EKS 클러스터간에 통신이 가능하도록 해줘야 한다. 

ebs 테스트 준비 완료

이제 아까처럼 pv/pvc 로 마운트하여 테스트해보자.

위와같이 pvc 생성하고 해당 pvc를 마운트하는 파드를 새로 생성하면 아래와같이 새로운 볼륨이 생성된것을 확인할수있다.

이와같이 파드에 EBS를 마운트하여 사용할수있다. 또한 기존 aws ebs와 마찬가지로 용량 증설도 가능하다.(반대로 축소는 불가능)

이번엔 볼륨 스냅샷에 대해 알아보자. 이또한 EKS의 개념이 아닌 aws내 ebs 의 스냅샷 기능을 이용하는것.

```bash
# (참고) EBS CSI Driver에 snapshots 기능 포함 될 것으로 보임
kubectl describe pod -n kube-system -l app=ebs-csi-controller

# Install Snapshot CRDs
curl -s -O <https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml>
curl -s -O <https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml>
curl -s -O <https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml>
kubectl apply -f snapshot.storage.k8s.io_volumesnapshots.yaml,snapshot.storage.k8s.io_volumesnapshotclasses.yaml,snapshot.storage.k8s.io_volumesnapshotcontents.yaml
kubectl get crd | grep snapshot
kubectl api-resources  | grep snapshot

# Install Common Snapshot Controller
curl -s -O <https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml>
curl -s -O <https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml>
kubectl apply -f rbac-snapshot-controller.yaml,setup-snapshot-controller.yaml
kubectl get deploy -n kube-system snapshot-controller
kubectl get pod -n kube-system -l app=snapshot-controller

# Install Snapshotclass
curl -s -O <https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/snapshot/manifests/classes/snapshotclass.yaml>
kubectl apply -f snapshotclass.yaml
kubectl get vsclass # 혹은 volumesnapshotclasses
```

 위와같이 준비 진행

위와같이 볼륨 스냅샷을 apply하면 아래와같이 스냅샷이 생성된것을 확인할수있다.

그럼 장애를 재연해서 스냅샷으로 복원해보도록 하자.

위와같이 실수록 삭제한 상황에서

우선 위와같이 datasource를 ebs볼륨 스냅샷을 가지고 pvc를 생성해주고

위와같이 스냅샷을 이용하여 생성한 pvc를 가지고 파드를 생성해주면 

위와같이 기존에 가지고 있떤 스냅샷을 가지고 ebs를 생성된것이 확인된다.

이번엔 efs에 대해 진행할것이다.

우선 efs의 구성 및 아키텍쳐는 다음과 같다.

(처음 efs 에 대해 공부할때 AWS에 있는 NFS로 이해했었다.)

# EFS 정보 확인 
aws efs describe-file-systems --query "FileSystems[*].FileSystemId" --output text

# IAM 정책 생성
curl -s -O <https://raw.githubusercontent.com/kubernetes-sigs/aws-efs-csi-driver/master/docs/**iam-policy-example.json**>
aws iam create-policy --policy-name **AmazonEKS_EFS_CSI_Driver_Policy** --policy-document file://iam-policy-example.json

# ISRA 설정 : 고객관리형 정책 AmazonEKS_EFS_CSI_Driver_Policy 사용
eksctl create **iamserviceaccount** \\
  --name **efs-csi-controller-sa** \\
  --namespace kube-system \\
  --cluster ${CLUSTER_NAME} \\
  --attach-policy-arn arn:aws:iam::${ACCOUNT_ID}:policy/AmazonEKS_EFS_CSI_Driver_Policy \\
  --approve

****# ISRA 확인
kubectl get sa -n kube-system efs-csi-controller-sa -o yaml | head -5
****eksctl get iamserviceaccount --cluster myeks

# EFS Controller 설치
helm repo add aws-efs-csi-driver <https://kubernetes-sigs.github.io/aws-efs-csi-driver/>
helm repo update
helm upgrade -i aws-efs-csi-driver aws-efs-csi-driver/aws-efs-csi-driver \\
    --namespace kube-system \\
    --set image.repository=602401143452.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/eks/aws-efs-csi-driver \\
    --set controller.serviceAccount.create=false \\
    --set controller.serviceAccount.name=efs-csi-controller-sa

# 확인
helm list -n kube-system
kubectl get pod -n kube-system -l "app.kubernetes.io/name=aws-efs-csi-driver,app.kubernetes.io/instance=aws-efs-csi-driver"

LB나 EBS와 마찬가지로 IRSA 셋팅해준다.

이제 efs를 마운트한 파드를 배포해보자.

위와같이 EFS가 연결돼있는 PV/PVC를 생성해주고

위와같이 파드 2개를 생성해준다.

위와같이 2개의 파드와 맨 처음 해당 실습을 진행했을때 배스천호스트에 마운트해놨던 efs까지 확인할수있다.

즉 현재 방금 배포한 2개의 파드와 실습용ec2 인스턴스는 한개의 efs 볼륨을 공유해서 사용하고있는상황
(예전 온프레미스 환경에서 NFS는 실시간 동기화필요할때(업로드 디렉토리처럼) 많이 사용했었음)

목표

EKS 네트워크의 이해
각각의 노드내 파드에서의 통신(내/외부) 흐름 이해

1. 실습 환경 배포

https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/eks-oneclick.yaml 을 통해 실습환경구축

Stackname, keyName, Accesskey, secret key 입력

SgIngressSshCidr 은 본인 아이피 입력

나머지는 자동

ps.

비용아끼겠다고 t3말고 t2로 하면 1시간도 더 걸린다. 그러니 그냥 t3로 진행할것

관리용 ec2 접속

에러는 아직 클라우드 포메이션이 전부 배포가 되지 않았기 때문이다.

# default 네임스페이스 적용 kubectl ns default



# 노드 정보 확인 kubectl get node --label-columns=node.kubernetes.io/instance-type,eks.amazonaws.com/capacityType,topology.kubernetes.io/zone eksctl get iamidentitymapping --cluster myeks



# 노드 IP 확인 및 PrivateIP 변수 지정

N1=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2a -o jsonpath={.items[0].status.addresses[0].address})

N2=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2b -o jsonpath={.items[0].status.addresses[0].address})

N3=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2c -o jsonpath={.items[0].status.addresses[0].address})

echo "export N1=$N1" >> /etc/profile

echo "export N2=$N2" >> /etc/profile

echo "export N3=$N3" >> /etc/profile

echo $N1, $N2, $N3

# 노드 보안그룹 ID 확인 NGSGID=$(aws ec2 describe-security-groups --filters Name=group-name,Values=*ng1* --query "SecurityGroups[*].[GroupId]" --output text) aws ec2 authorize-security-group-ingress --group-id $NGSGID --protocol '-1' --cidr 192.168.1.100/32



# 워커 노드 SSH 접속

ssh ec2-user@$N1 hostname

ssh ec2-user@$N2 hostname

ssh ec2-user@$N3 hostname

위 작업들을 순서대로 진행하면 N1, N2, N3(노드1,2,3)서버로 접속이 가능해진다.

여기까지 하면 2주차 실습 준비 완료

온프레미스 k8s에 가장 많이 사용되는 CNI인 Calico와 AWS EKS에 가장 많이 사용되는 AWS VPC CNI의 차이점은 다음과 같다.

- Calico의 경우 파드와 노드의 대역이 다르지만 AWS VPC CNI는 네트워크 통신 최적화를 위해 파드와 노드의 대역이 같다.

- Calico는 오버레이(인캡슐 디캡슐진행) 통신을 하고 AWS VPC CNI는 동일대역으로 직접 통신

AWS VPC CNI를 구축할때 주의할점은 네트워크 대역을 보통 24비트로 하는경우가 많을텐데(나만 그런가...) AWS VPC CNI의 경우 파드 네트워크와 노드 네트워크가 공유되기때문에 네트워크 대역을 여유롭게 22비트 정도로 주는게 좋다.

위와같이 노드1,3에는 eni~로 가상의 네트워크가 추가돼있는데 이것들이 각각 노드1,3에 추가돼있는 파드의 네트워크 정보이다.

t3.medium의 경우 ENI별로 6개의 아이피를 할당받을수있는데 아래와같이 node1,3은 ENI가 2개라 보조 프라이빗 IP까지 총 12개가 할당된것을 볼수있고 node2는 6개가 할당된것을 볼수있다.

위와같이 노드1,3에는 보조 프라이빗 ip주소가 생성돼있는걸 확인할수있는데 노드2에는 파드가 추가돼있지 않아서 기본적으로 할당되는 6개(1개는 프라이빗으로 실제 할당이됐고 나머지5개)만 할당돼있는걸 확인할 수 있다.

여기서 replicas 3을 줘서 각각의 노드에 파드를 1개씩 추가로 생성되도록 해보면 결과는 아래와 같다.

보는것처럼 각각의 노드에 ENI가 1개씩 추가된것을 확인할수있다.

그럼 실제 할당된 아이피 갯수는 몇개일까

보는것처럼 노드2는 6개의 아이피가 추가된것을 확인할수있다. 다만 노드1,3은 아까와 동일하다.

그렇다. 파드가 추가(ENI가 생성)된다고 해서 무조건 새로운 아이피가 할당되는게 아니다.

ENI 가 생성되는 프로세스는 다음과같다.

IP POOL에 내용이 없으면 세컨더리 ENI를 생성(방금 노드2번의 경우) 그게 아니라면 기존 IP POOL에서 아이피를 할당하는것이다.

이렇게 IP POOL이 부족하면 새로운 ENI를 생성하는건데 무제한으로 생성되지 않는다.

온프레미스에서는 iptables의 NAT 구성으로 트래픽을 포워딩 해주는데  eks는 하나의 네트워크 대역에 들어가니까 확실히 calico(온프레미스용 CNI)보다 네트워크 구성을 이해하기가 더 좋은거같다. 그렇기 때문에 문제가 발생했을경우 어떤구간에서 문제가 발생했는지 좀더 직관적(동일 네트워크이기에 원인 파악이 쉬움)으로 트러블 슈팅이 가능할것이다.

실제로 노드내 파드끼리, 통신을 해보자.

https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/cni-proposal.md

위와같은 플로우로 진행이 되는데 실제로 실습을 해보고자 한다.

위와같이 파드2에서 ping 하여 tcpdump 해보면 pod1의 아이피로 통신하는것을 확인할수 있다.

이번엔 파드에서 외부로 나가는 통신을 확인해보자.

위와같이 파드1에서 google.com 으로 통신을 한 결과이다.

일단 ping이 정상적인거보면 통신은되는데... 172.217.31.132가 실제 구글 아이피는 아니다.

google의 아이피는 172.217.31.132가 아닌데 tcpdump의 결과는 172.217.31.132로 통신을 보내고있다.

그러면 172.217.31.132 에서 또 다른곳으로 NAT를 통해 실제 google로 통신이 되고 있는것이다.

다시 말하자면 파드의 실제 외부아이피(즉 외부 인터넷(구글)과 통신할 아이피)는 사설망 아이피(192나 172.로 시작하는게 아닌)가 아닌 외부 아이피로 통신을 해야한다. 

이건 iptables의 SNAT를 통해 통신이 된다.

iptables 설정은 위와같다.

위와같이 192.168(클러스터 내 파드들의 대역)은 AWS SNAT-CHAIN으로 통신을 하고 그 외 나머지는 192.168.1.190아이피 달고 가라. 그럼 라우팅 설정에 의해 외부(인터넷)으로 통신이 되는것이다.

위와같이 각 pod별로 아이피가 할당이되고 통신되는것을 알아보았는데. 파드에 할당되는 아이피는 설정한 대역내 랜덤으로 아이피가 할당된다. 그럼 실제 서비스를 하기위해 파드로의 통신은 어떻게 해야할까.

service 라는 리소스 오브젝트로 VIP를 만들어서 파드로 통신이 가능하다.

서비스 종류는 다음과 같다.

이중 NLB+AWS VPC CNI의 경우 앞단의 NLB에서 파드로 바로 통신이 가능하다. 이것이 가능한 이유는 node의 아이피대역과 파드의 아이피 대역이 같은 AWS VPC CNI의 특징때문이다. 

즉 노드내 iptables나 contrack와 같은 자원을 사용하지 않아 불필요한 자원이 사용되지 않고 통신구간이 줄어드는 장점이 있다.

다만 k8s와 AWS 로드밸런서(NLB)간에 어떠한 통신을하며 k8s 파드가 늘거나 혹은 줄어듬에 따라 NLB에서 대상타깃이 추가/제거가 필요하기 때문이다. 이는 k8s 클러스터내에 존재하는 load balancer controller 파드와 AWS의 서비스인 로드밸런서(NLB)간에 인증(OIDC)절차가 진행/완료되어 파드 IP등 지속적인 정보를 제공해주도록 해야한다.

인증 절차 진행을 위한 작업 IRSA 으로 진행한다.

인증 방법은 아래와같다.

# OIDC 확인
aws eks describe-cluster --name $CLUSTER_NAME --query "cluster.identity.oidc.issuer" --output text
aws iam list-open-id-connect-providers | jq

# IAM Policy (AWSLoadBalancerControllerIAMPolicy) 생성
curl -o iam_policy.json https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.4.7/docs/install/iam_policy.json
aws iam create-policy --policy-name AWSLoadBalancerControllerIAMPolicy --policy-document file://iam_policy.json

# 혹시 이미 IAM 정책이 있지만 예전 정책일 경우 아래 처럼 최신 업데이트 할 것
# aws iam update-policy ~~~

# 생성된 IAM Policy Arn 확인
aws iam list-policies --scope Local
aws iam get-policy --policy-arn arn:aws:iam::$ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy
aws iam get-policy --policy-arn arn:aws:iam::$ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy --query 'Policy.Arn'

우선 OIDC 를 설정(클라우드 포메이션으로 자동 설정)하면 아래와 같이 EKS 클러스터에서 OIDC 가 설정돼있음을 확인할수있고

IAM 폴리시를 생성하면

위와같이 IAM 폴리시가 추가된것을 확인할수 있다.

여기까지하면 aws EKS에서는 OIDC를 통해 인증을 진행할 준비가 됐고 IAM 폴리시를 추가하여 EKS 클러스터에서 AWS 로드밸런서를 컨트롤할수있는 권한을 가져올 준비가 끝났다.

이제 IRSA를 통해 컨트롤이 가능하도록 구성하면된다.

방법은 아래와 같다.

# AWS Load Balancer Controller를 위한 ServiceAccount를 생성 >> 자동으로 매칭되는 IAM Role 을 CloudFormation 으로 생성됨!
# IAM 역할 생성. AWS Load Balancer Controller의 kube-system 네임스페이스에 aws-load-balancer-controller라는 Kubernetes 서비스 계정을 생성하고 IAM 역할의 이름으로 Kubernetes 서비스 계정에 주석을 답니다
eksctl create iamserviceaccount --cluster=$CLUSTER_NAME --namespace=kube-system --name=aws-load-balancer-controller \
--attach-policy-arn=arn:aws:iam::$ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy --override-existing-serviceaccounts --approve

## IRSA 정보 확인
eksctl get iamserviceaccount --cluster $CLUSTER_NAME

## 서비스 어카운트 확인
kubectl get serviceaccounts -n kube-system aws-load-balancer-controller -o yaml | yh

eksctl을 통해 서비스 어카운트를 생성하고 이는 클라우드포메이션을 통해 추가로 배포된다.

이제 모든 준비가 끝났으니 로드밸런서 컨트롤러를 EKS 클러스터에 헬름차트를 통해 배포하여 사용해보자.

helm repo add eks https://aws.github.io/eks-charts
helm repo update
helm install aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=$CLUSTER_NAME \
  --set serviceAccount.create=false --set serviceAccount.name=aws-load-balancer-controller

이후 로드밸런싱이 어떻게 구성되는지 확인하기 위해 아래와같이 테스트로 서비스와 파드를 배포하면

curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/2/echo-service-nlb.yaml
cat echo-service-nlb.yaml | yh
kubectl apply -f echo-service-nlb.yaml

아래와같이 enpoint가 두개(192.168.2.101, 192.168.3.75)로 로드밸런싱되도록 배포 된것을 확인할수 있다.

여기서 중요한부분은 앞서 말한것처럼 NLB에서 다이렉트로 파드의 아이피로 간다는것이다. 

이것이 가능한이유는 AWS VPC CNI의 장점인 노드아이피와 파드의 아이피가 동일한 대역이라 가능하기 때문이다.

실제 AWS 로드밸런서를 확인해보면

위와같이 eks 클러스터에서 AWS 로드밸런서 서비스가 생성된것을 확인할수있다.

이것이 가능한것은 앞서 클러스터에서는 OIDC, AWS에는 IAM 정책을 생성해줬고 이를 IRSA로 설정해줬기 때문이다.

실습 완료후 자원 삭제 

aws cloudformation delete-stack --stack-name eksctl-$CLUSTER_NAME-addon-iamserviceaccount-kube-system-aws-load-balancer-controller

텔레포트란 ?
Teleport is an open-source tool that provides zero-trust access to servers and cloud applications using SSH, Kubernetes and HTTPS. It eliminates the complexity of setting up VPNs by providing a secure gateway to applications, servers and Kubernetes clusters. It was open-sourced by Gravitational Inc

시스템엔지니어나 IT담당자. 데브옵스엔지니어등 사내 인프라담당자, 관리자들은 여러 서비스에 접근이 필요하다.

1. 관리하고 있는 온프렘의 수십 수백대의 서버.

2. pgsql, mariadb등 수많은 디비들
3. k8s 
4. 각종 어플리케이션

5. aws등

위와같이 여러 서비스를 관리해야하기에 각각의 로그인 창구가 필요하다. 이를 하나의 창구로 통일시키면 다음과 같은 장점이 생긴다.

1. 편리함 - SSH를통한 서버로의 접속이나 클러스터, 데이터베이스, 리모트데스크톱, 웹 애플리케이션등에 액세스할때 각각의 로그인 창구가 아니라 Teleport 하나의 단일 솔루션으로 로그인 하니까.

2. 보안 향상
2-1) 세션 레코딩
2-2) 제로 트러스트

2-3) 감사 로그

1. 로그인 시스템

1-1) 계정별로 환경 분리 - 개발/운영 계정 별도로

1-2) 로그인 창구 최소화 - 대표계정 하나에서 로그인하고 이후 dev / prod 로 어쓔밍

1-3) 침해사고시 영향 최소화  - 각 계정별 접근권한 최소화

2. 서버 접근 - Teleport. 세션 레코딩 기능이 가장 매력적임. linux의 script 명령어가 훨씬 더 깔금하게 저장된다고 생각하면될듯

3. 인프라는 뭘로 ? - k8s

4. CI/CD 파이프라인 - 

5. 모니터링

6. APM

EKS는 제대로 써본적이 없어서 이번에 한번 공부해봐야겠다 싶어 신청했는데 좋은 기회가 왔다. aws 워크샵을 토대로 여러 쟁쟁한 분들께서 참여&도움주시는 스터디다.
유튜브부터 각종 커뮤니티에서 활동하시는 정말 현업에서 쟁쟁하신분들께서 함께 공유에 힘쓰는 모습이 멋있다는 생각이 든다.

특히 유튜브 악분일상님보고 너무 반가웠다. 개인적으로 공부법이 자기전에 그냥 틀어놓고 자는건데 악분일상님 유튜브 많이 틀어놓는데.. 혼자서 반가웠다.

여튼 알려주신 회사동료와 좋은 교육을 제공해주시는 모든 분들께 감사인사를 표해야겠다.

이 글의 목표
eks교육 1주차를 듣고... 내가 아는 IT 지인들중 쿠버네티스(EKS) 이름만 들어보고 뭔지 모르는 사람들이 이 글을 읽고 언제 어떻게 왜 써야 하는지 알게끔 하기.
최대한 간략하고 이해하기 쉽게 쓰기.

시작.

1. EKS란 

AWS에서 제공하는 쿠버네티스 서비스.
쿠버네티스란 컨테이너가 한두개면 상관없는데 너~무 많아지면서(컨테이너당 서비스 하나가 표준) 컨테이너 관리가 어려워졌다. 그래서 나온게 k8s.
k8s란 컨테이너 오케스트레이션 도구. 컨테이너 인프라를 더 똑똑하게 효율적으로 잘 관리해주는 도구.
ㄴ똑똑하고 효율적이다 : 자원을 모니터링해서 오토힐링, 오토스케일링등

컨테이너란 ? https://kk-7790.tistory.com/135 참고

컨테이너를 왜쓰지 ? 
1. 서비스 이식성 - 어떤 OS건 도커등 컨테이너 실행환경만 갖춰진 OS라면 바로 실행이 가능하다. 
2. 빠른 복구 - 서비스 이식성이 좋기 때문에 서버 다운시 다른 서버로 빠르게 복구가 가능하다.
ㄴbefore : 기존 서버와 동일한 아파치,php, mysql 설치하고 설정파일 복사해서 붙여넣고 등등...
ㄴafter : 컨테이너만 기존꺼랑 맞게 실행해주면 끝(주기적으로 변경되는 데이터(DB등)은 당연히 리스토어해야함)

3. 배포 및 관리 단순화 - 통일된 인프라(도커 컨테이너라는)가 되기 때문에 오퍼레이터 입장에서 상당히 편해짐
ㄴbefore : OS별로 설치,배포방법 다름...
ㄴafter : OS위에 도커만 설치하면 그 뒤부터는 도커위에 컨테이너 올려서 사용. 

이외에도 여러 장점이 있음.

요약하자면
1. 컨테이너의 장점이 워낙 뚜렷하기때문에 현재 IT 인프라는 컨테이너 기반이 표준이 됐다.

2. 근데 관리해야할 컨테이너가 너무 많아짐에따라 관리도구가 필요했고 그게 K8S다.

3. EKS는 aws에서 제공하는 k8s 서비스

2. EKS와 쿠버네티스의 차이

쿠버네티스 - 온프레미스에 직접 설치해서 사용해야함. 그래서 쿠버네티스에 필요한 구성요소들. 컨트롤플레인등을 직접 설치하고 관리해줘야한다.

EKS - 관리에 필요한 구성요소들을 제외(aws에서 관리해줌)하고 실제 서비스 운영에 필요한 요소(워커노드)만 관리하면 된다. 

예를들어 l7 로드밸런싱에 엔진엑스 리버스프록시서버 1대, 실제 서비스 서버2대 총 3대가 있을경우

k8s - 3대 모두 직접 구성하고 관리해줘야함. 특히 리버스 프록시 서버 도구 설치부터 설정, 이후 관리(고가용성등)까지.

EKS - 실제 운영되는 서버 2대만 관리하면됨. 그 2대도 aws에서 구축(ec2)해준다. 관리만 하면됨.

꼭 k8s(eks)를 써야하나...?

꼭 그렇진 않다. 클러스터가 필요하지 않은 환경. 대표적으로 접속자가 일정하고 한대의 서버에서 충분히 커버가 가능하고 어느정도의 다운타임(업무시간에 30분정도 ?)이 허용되는 환경이라면 k8s를 굳이 사용할필요는 없다. 컨테이너 환경으로도 충분하다.

그럼에도 k8s를 구축하면 좋은점은 소유한 서버들의 리소스를 최대한 효율적으로 사용할 수 있다. 반대로 k8s를 도입함으로써의 쓰이는 인적자원도 있고... 잘 생각해보고 도입하면 된다. 도입할 여건(운영지식)만 된다면 실보단 득이 더 많다고 본다.

4. EKS 아키텍처

용어 설명

controlplane(master node) -  k8s 클러스터를 제어노드

dataplane(worker node) - 실제 데이터(파드,볼륨등)이 쌓이고 자원(cpu, 메모리)이 사용되는 노드

kubectl - 쿠버네티스 제어 도구. eks의 경우 컨트롤플레인 서버에 직접 접속이 안되니까 외부에 kubectl 설치해서 컨트롤플레인(마스터노드)의 api server로 명령을 전달한다.

Scheduler - 새로운 파드를 상황에 맞게 노드에 할당하는 역할

API server - 모든 컴포넌트들사이에서 api 서버 역할을 하며 통신해주는 역할

etcd - 데이터 저장소

controller manager - 클러스터 상태를 감시(오토힐링, 오토스케일링을위한)하고 작업을 수행하는 역할

kubelet - 워커노드의 상태 관리

kube-proxy - 네트워크 역할

아키텍처를 알아봤으니 어떻게 동작하는지도 알아보자. deployment로 파드를 배포했을때의 동작과정은 다음과같다.

1. 파드 생성 - 사용자가 kubectl run 명령어 타이핑 엔터

2. kubectl에서 컨트롤플레인(마스터노드)의 apiserver에 전달

3-1. apiserver가 etcd에 생성에 관한 정보(unscheduled pod)를 etcd에 저장

3-2. 동시에 apiserver가 etcd에 deployment에 포함된 replicas에 관한 정보를 etcd에 저장

4. scheduler는 unscheduled pod를 감지

5. 이후 scheduler가 어떤 워커노드에 배포할지 확인

6. 정해진 노드를 apiserver에 전달

7. api서버는 그 노드를 etcd에 또 저장

8. kubelet이 api서버에서 해당 노드에 파드를 배포

최대한 간략하게 적었고 자세한건.

https://blog.eunsukim.me/posts/understanding-how-kubernetes-works

참고

개인적으로 쿠버네티스, eks나 깃랩이나 여러 솔루션, 도구들을 관리하는 서버 관리자라면 해당 도구들의 아키텍쳐와 주요 컴포넌트들. 그 컴포넌트들이 어떤일을 왜 하는지정도는 알아야 한다고 생각한다.

허나 개발자들이 클라우드 환경에서 사용한다면 알면 좋겠지만 몰라도 괜찮다고는 생각한다.(그래야 우리같은 엔지니어가 밥벌이를 하니까..) 여튼 개발자분들은 다른 컴포넌트들은 몰라도 되는데 알아야할건 apiserver이다.

어떤 컴포넌트들이건 무조건 apiserver 와 통신을 한다. 심지어 외부에서 접근할때도 apiserver 서버와 통신을한다. 

온프렘에 설치한 k8s를 컨트롤하기 위한 kubeadmin 명령어대신 K8s.domain.co.kr/api 로도 통신이 가능하다.

5. EKS 구축방법

• 기본 인프라 배포 - 링크 ← AWS CloudFormation 페이지로 연결되며, 파라미터 입력 후 스택 실행
• CLI 를 이용하여 배포 (CLI를 사용하기 위해선 aws confiure 설정이 완료되어야 한다)

# yaml 파일 다운로드
curl -O <https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/**myeks-1week.yaml**>

# 배포
# aws cloudformation deploy --template-file ~/Downloads/myeks-1week.yaml --stack-name mykops --parameter-overrides KeyName= SgIngressSshCidr=/32 --region <리전>
예시) aws cloudformation deploy --template-file ~/Downloads/**myeks-1week.yaml** \\
     --stack-name **myeks** --parameter-overrides KeyName=**kp-gasida** SgIngressSshCidr=$(curl -s ipinfo.io/ip)/32 --region ap-northeast-2

# CloudFormation 스택 배포 완료 후 EC2 IP 출력
aws cloudformation describe-stacks --stack-name **myeks** --query 'Stacks[*].Outputs[*].OutputValue' --output text
예시) 3.35.137.31

# ec2 에 SSH 접속
예시) ssh -i  **ec2-user**@3.35.137.31
ssh -i **~/.ssh/kp-gasida.pem** ec2-user@$(aws cloudformation describe-stacks --stack-name **myeks** --query 'Stacks[*].Outputs[0].OutputValue' --output text)

• IAM User 자격 증명 설정 및 VPC 확인 및 변수 지정

# 자격 구성 설정 없이 확인
**aws ec2 describe-instances**

# IAM User 자격 구성 : 실습 편리를 위해 administrator 권한을 가진 IAM User 의 자격 증명 입력
**aws configure**
AWS Access Key ID [None]: ***AKIA5...***
AWS Secret Access Key [None]: ***CVNa2...***
Default region name [None]: ***ap-northeast-2***
Default output format [None]: json

# 자격 구성 적용 확인 : 노드 IP 확인
**aws ec2 describe-instances**

# EKS 배포할 VPC 정보 확인
**aws ec2 describe-vpcs --filters "Name=tag:Name,Values=$CLUSTER_NAME-VPC" | jq**
aws ec2 describe-vpcs --filters "Name=tag:Name,Values=$CLUSTER_NAME-VPC" | jq Vpcs[]
aws ec2 describe-vpcs --filters "Name=tag:Name,Values=$CLUSTER_NAME-VPC" | jq Vpcs[].VpcId
aws ec2 describe-vpcs --filters "Name=tag:Name,Values=$CLUSTER_NAME-VPC" | jq -r .Vpcs[].VpcId
**export VPCID=$(aws ec2 describe-vpcs --filters "Name=tag:Name,Values=$CLUSTER_NAME-VPC" | jq -r .Vpcs[].VpcId)
echo "export VPCID=$VPCID" >> /etc/profile**
echo VPCID

****# EKS 배포할 VPC에 속한 Subnet 정보 확인
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$VPCID" --output json | jq
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$VPCID" --output yaml | yh

****## 퍼블릭 서브넷 ID 확인
**aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-PublicSubnet1" | jq**
aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-PublicSubnet1" --query "Subnets[0].[SubnetId]" --output text
**export PubSubnet1=$(aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-PublicSubnet1" --query "Subnets[0].[SubnetId]" --output text)
export PubSubnet2=$(aws ec2 describe-subnets --filters Name=tag:Name,Values="$CLUSTER_NAME-PublicSubnet2" --query "Subnets[0].[SubnetId]" --output text)
echo "export PubSubnet1=$PubSubnet1" >> /etc/profile
echo "export PubSubnet2=$PubSubnet2" >> /etc/profile**
echo $PubSubnet1
echo $PubSubnet2

• Amazon EKS 배포 실습

# 변수 확인
echo $AWS_DEFAULT_REGION
echo $CLUSTER_NAME
echo $VPCID
echo $PubSubnet1,$PubSubnet2

# 옵션 [터미널1] EC2 생성 모니터링
#while true; do aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,PrivateIPAdd:PrivateIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output text ; echo "------------------------------" ; sleep 1; done
**aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,PrivateIPAdd:PrivateIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output table**

# eks 클러스터 & 관리형노드그룹 배포 전 정보 확인
**eksctl create cluster --name $CLUSTER_NAME --region=$AWS_DEFAULT_REGION --nodegroup-name=$CLUSTER_NAME-nodegroup --node-type=t3.medium \\
--node-volume-size=30 --vpc-public-subnets "$PubSubnet1,$PubSubnet2" --version 1.24 --ssh-access --external-dns-access --dry-run | yh**
...
**vpc**:
  autoAllocateIPv6: false
  cidr: 192.168.0.0/16
  clusterEndpoints:
    privateAccess: false
    publicAccess: true
  **id**: vpc-0505d154771a3dfdf
  manageSharedNodeSecurityGroupRules: true
  nat:
    gateway: Disable
  **subnets**:
    **public**:
      ap-northeast-2a:
        az: ap-northeast-2a
        cidr: 192.168.1.0/24
        id: subnet-0d98bee5a7c0dfcc6
      ap-northeast-2c:
        az: ap-northeast-2c
        cidr: 192.168.2.0/24
        id: subnet-09dc49de8d899aeb7
****
# eks 클러스터 & 관리형노드그룹 배포: 총 16분(13분+3분) 소요 
**eksctl create cluster --name $CLUSTER_NAME --region=$AWS_DEFAULT_REGION --nodegroup-name=$CLUSTER_NAME-nodegroup --node-type=t3.medium \\
--node-volume-size=30 --vpc-public-subnets "$PubSubnet1,$PubSubnet2" --version 1.24 --ssh-access --external-dns-access --verbose 4**
...
023-04-23 01:32:22 [▶]  setting current-context to admin@myeks.ap-northeast-2.eksctl.io
2023-04-23 01:32:22 [✔]  **saved kubeconfig as "/root/.kube/config"**
...

eks 클러스터 & 관리형노드그룹 배포 전

배포 완료

AWS CloudFormation 확인

AWS EKS 확인

Daemon Set pod를 통한 pod가 통신하는 ENI 확인

# 노드 IP 확인
aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,PrivateIPAdd:PrivateIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output table

# PrivateIP 변수 지정
N1=<PrivateIPAdd.myeks-myeks-nodegroup-Node1>
N2=<PrivateIPAdd.myeks-myeks-nodegroup-Node2>

# 노드 보안그룹 ID 확인
aws ec2 describe-security-groups --filters Name=group-name,Values=*nodegroup* --query "SecurityGroups[*].[GroupId]" --output text
NGSGID=$(aws ec2 describe-security-groups --filters Name=group-name,Values=*nodegroup* --query "SecurityGroups[*].[GroupId]" --output text)
echo $NGSGID

# 노드 보안그룹에 eksctl-host 에서 노드(파드)에 접속 가능하게 룰(Rule) 추가 설정
aws ec2 authorize-security-group-ingress --group-id $NGSGID --protocol '-1' --cidr 192.168.1.100/32

# eksctl-host 에서 노드의IP나 coredns 파드IP로 ping 테스트
ping -c 2 $N1
ping -c 2 $N2

# kubelet, kube-proxy 통신 Peer Address 확인
ssh -i ~/.ssh/id_rsa ec2-user@$N1 sudo ss -tnp
ssh -i ~/.ssh/id_rsa ec2-user@$N2 sudo ss -tnp

# aws-node 데몬셋 파드 1곳에 bash 실행해두기 
kubectl exec daemonsets/aws-node -it -n kube-system -c aws-node -- bash

# 추가된 kubelet, kube-proxy 통신 Peer Address 확인
ssh -i ~/.ssh/id_rsa ec2-user@$N1 sudo ss -tnp
ssh -i ~/.ssh/id_rsa ec2-user@$N2 sudo ss -tnp

aws-node 데몬셋에 bash 실행 전

• aws-node 데몬셋에 bash 실행 후
  • 실행 후 IP 확인을 해보면 추가된 연결정보를 확인할 수 있다.
    • 추가된 IP : 192.168.2.240

• 추가된 연결된 정보(192.168.2.240)를 확인하기 위해 ENI를 확인
  • ENI가 추가로 생성되어있고 “소유자”와 “요청자”가 다르다.

• 실습 완료 후 자원 삭제

# Amazon EKS 클러스터 삭제 (약 10분 소요)
eksctl delete cluster --name $CLUSTER_NAME

# 클러스터 삭제 완료 후 AWS CloudFormmation 스택 삭제
aws cloudformation delete-stack --stack-name myeks

devops, se 관점에서 Keycloak을 운영할때 필요한 것들을 알아본다.

1. IAM 관리시 알아야할것들

1-1) 계정 생성 및 관리
  패스워드 분실등 관리자가 서버 이벤트에 대한 알림을 받을 이메일 발송에 필요한 SMTP 설정

1-2) 그룹 생성 및 관리

1-3) realm 생성 및 관리

realm을 어떻게 관리하는게 B/P일까 ?
우선 마스터 realm은 시스템 관리(other realm 생성 관리)에만 사용해야하고 실제 클라이언트는 용도에 맞게 other realm을 생성해서 포함시켜줘야 한다.

그렇다면 Realm은 어떤 환경에따라 분류를 해줘야할까 ?

2. 디비 백업

3. 로그 관리

4. 주요 SP별 연동 방법

5. 알아두면 좋은 기능들

6. 고가용성 방안

7. 이중화

8. 실 서비스에 keycloak 사용하는법(keycloak을 브로커로 구성)

1. 인증되지 않은 사용자가 클라이언트 애플리케이션에서 보호된 리소스를 요청합니다.

2. 클라이언트 애플리케이션은 인증하기 위해 사용자를 Keycloak으로 리디렉션합니다.

3. Keycloak은 영역에 구성된 ID 공급자 목록이 있는 로그인 페이지를 표시합니다.

4. 사용자는 버튼 또는 링크를 클릭하여 ID 공급자 중 하나를 선택합니다.

5. Keycloak은 인증을 요청하는 대상 ID 공급자에게 인증 요청을 발급하고 사용자를 ID 공급자의 로그인 페이지로 리디렉션합니다. 관리자는 이미 관리 콘솔의 ID 공급자에 대한 연결 속성 및 기타 구성 옵션을 설정했습니다.

6. 사용자가 자격 증명을 제공하거나 ID 공급자에 인증하는 데 동의합니다.

7. ID 공급자가 인증에 성공하면 사용자는 인증 응답과 함께 Keycloak으로 다시 리디렉션됩니다. 일반적으로 이 응답에는 Keycloak에서 ID 공급자의 인증을 신뢰하고 사용자 정보를 검색하는 데 사용하는 보안 토큰이 포함됩니다.

8. Keycloak은 ID 공급자의 응답이 유효한지 확인합니다. 유효한 경우, 사용자가 아직 존재하지 않는 경우 Keycloak는 사용자를 가져와서 만듭니다. 토큰에 해당 정보가 포함되어 있지 않은 경우 Keycloak는 ID 공급자에게 추가 사용자 정보를 요청할 수 있습니다. 이 동작을 ID 페더레이션이라고 합니다. 사용자가 이미 존재하는 경우, Keycloak는 ID 공급자로부터 반환받은 ID를 기존 계정과 연결하도록 사용자에게 요청할 수 있습니다. 이 동작을 계정 연결이라고 합니다. Keycloak에서는 계정 연결을 구성하고 첫 로그인 플로우에서 계정 연결을 지정할 수 있습니다. 이 단계에서 Keycloak은 사용자를 인증하고 토큰을 발급하여 서비스 공급자의 요청된 리소스에 액세스할 수 있도록 합니다.
9. 사용자가 인증하면 Keycloak은 로컬 인증 중에 이전에 발급한 토큰을 전송하여 사용자를 서비스 공급자로 리디렉션합니다.
10. 서비스 공급자는 Keycloak으로부터 토큰을 받고 보호된 리소스에 대한 액세스를 허용합니다.

이 흐름의 변형이 가능합니다. 예를 들어, 클라이언트 애플리케이션에서 ID 공급자의 목록을 표시하지 않고 특정 공급자를 요청하거나, 사용자가 ID를 페더레이션하기 전에 추가 정보를 제공하도록 Keycloak을 설정할 수 있습니다.

인증 프로세스가 끝나면 Keycloak는 토큰을 클라이언트 애플리케이션에 발급합니다. 클라이언트 애플리케이션은 외부 ID 공급자와 분리되어 있으므로 클라이언트 애플리케이션의 프로토콜이나 사용자 신원을 검증하는 방법을 볼 수 없습니다. 공급자는 Keycloak에 대해서만 알면 됩니다.

구글 계정을통해 keycloak으로 연동한 saml로 실 서비스에 로그인하기.

version: '3.7'
services:
  reverse-proxy:
    image: traefik:v2.9
    restart: always
    ports:
      - '80:80' # http
      - '443:443' # https
      - '8080:8080' # https
    networks:
      - harbor
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./letsencrypt:/letsencrypt
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--providers.docker.network=harbor"
      - "--entrypoints.websecure.address=:443"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.ssh.address=:2222"
        #- "--entrypoints.web.http.redirections.entrypoint.to=websecure"
        #- "--entrypoints.web.http.redirections.entrypoint.scheme=https"
      - "--certificatesresolvers.myresolver.acme.tlschallenge=true"
      - "--certificatesresolvers.myresolver.acme.email=sabo@infograb.com"
      - "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"
      - "--certificatesresolvers.myresolver.acme.httpchallenge.entrypoint=web"
      - "--api.insecure=true"
networks:
  harbor:
    external: true

gitlab 과 keycloak을 연동해서 인증시스템을 구축해볼것이다.

그전에 관련 용어 설명

keycloak - 오픈소스 IAM 솔루션

okta - 상용 IAM 솔루션

IAM(Identity and Access Management) - User ID, 암호를 통해 계정을 생성&관리하고 권한을 할당하여 접근제어(인증, 인가, 감사등)

즉 IAM이란 어떤 솔루션이나 프로토콜을 의믜하는게 아니고 보안행위 및 규칙등을 의미하고

IAM을 하기 위한 솔루션으로 keycloak 과 Okta등이 있는것.

더 자세히 들어가보면 IAM 솔루션들의 구성요소, 프로토콜이나 보안 정책등을 알아보자면

1. SAML - 인증정보를 중앙 관리하여 한번의 디지털 서명(ID, PW)으로 설정돼있는 모든 리소스(SAML을 제공하는)에 접근 가능.
   로직은 다음과 같다.
   요청(사용자가 로그인 시도) > 검증(SAML과 IDP 연결) > 로그인(ID, Password 입력창 표시) > 토큰생성(사용자 정보 올바를시 SAML 토큰이 전송되어 서버에 로그인)

2. OAuth - 한번의 로그인(자격증명 성공)으로 얻은 토큰을 다른서비스에 로그인(인증)시 해당 토큰을 전달하는데 사용(ID,PW를 전달해주는게 아님). 단 조건은 사전에 IdP에서 사용자의 승인을 받아 리소스 서버에 토큰을 발행할수 있어야 함.

로직은 다음과 같다.

요청(사용자가 로그인 시도) > 선택(로그인 방법으로 타사 권한 인증 선택) > 로그인(인증 서버가 액세스 토큰 생성하여 리소스 서버에 전송) > 연결(리소스 서버가 토큰 확인후 접근 허용)

SAML과 OAuth의 유사점과 차이점은?

먼저 유사점은 SAML과 OAuth를 사용(한번의 로그인)으로 여러 서비스의 접근이 가능(SSO)해지는것.

예를들어 구글(IDP)계정을 가지고 깃랩도 로그인하고 페북도 로그인하고 플럼버도 로그인하고.. 이런것들이 SAML 혹은 OAuth를 가지고 SSO 기능을 구현했다라고 볼수있음.

차이점은 SAML=인증 / OAuth = 인가이다. SAML의 경우 구글(IDP)계정들의 아이디/패스워드들을 가지고 인증을 받아 다른 서비스에 로그인하는것.

OAuth는 구글에서 받은 토큰을 로그인 하려는 다른 서비스에 등록, 즉 권한을 허가 받아 다른서비스에 로그인하는것

로그인에 초점을 맞추면 둘중 하나만 사용하면 되고.

좀더 보안을 강화하려면 일단 로그인은 SAML(인증된자만)로 접근가능하도록 하고 그 서비스 로그인 이후의 하위서비스 접근은 OAuth(인가된자만)로 접근 가능하도록 처리하면 보안을 좀 더 강화할 수 있다

3. OIDC - 인증을 위해 OAuth에서 인증부분을 확장하여 구현된 프로토콜

OAuth에서 openid 스코프가 포함돼있으면 OIDC임. oauth 스코프에 openid가 있으면 oauth의 본래 목적인 액세스토큰(인가정보)외에 추가로 인증정보인 ID토큰(JWT)을 반환함.
##인증과 인가의 차이 : 인증 - 신원 검증 / 인가 - 권한 부여

즉 OIDC는 인가가 아닌 인증을 위해 OAuth에 인증이 확장된 개념이다.

앞의 내용을 다 이해했다면 OAuth와 OIDC를 각가 언제 사용해야 하는지 이해했을듯 하다.

그럼 둘다 인증이 목적인 SAML과 OIDC은 특징 및 장단점이 뭐고 각각 언제 쓰일까 ?

SAML - XML 기반, OIDC보다 상대적으로 느림, 메시지 크기가 큼, 20년전부터 널리 사용됐기에 스탠다드함. 따라서 기존 시스템과의 호환성이 높음. 기존 엔터프라이즈 환경에서 더 잘 어울려 왔음

OIDC - JSON 기반, 처리속도가 빠르고 사이즈가 작음. 최근(5~7년전)에 각광받고 있음. 여러 환경에서 사용됨.

장단점만을 본다면 OIDC가 더 좋아보이나 기존 엔터프라이즈 환경에서 SAML이 이미 많이 사용되고 있었기에 보안규정 및 지침등이 SAML에 맞게 표준화 돼 있었음. 따라서 아주 빡세게 보안규정을 지켜야한다면 OIDC보단 그에 맞는SAML을 채택하는게 맞고 그게 아니라면 OIDC가 더 유리하다고 판단됨

하여 아직까진 SAML을 많이 사용하나 OIDC도 많아지는 추세임.

그외 

SSO - 싱글사인온. 하나의 인증/인가로 해결하는것

IdP - identitiy provider. 즉 인증/인가정보를 제공하는곳.(구글, 카카오, 페이스북등)

JWT - Json웹 토큰 - 사용자 인증정보를 json 구조로 구성. OIDC가 JWT로 인증을 주고받음

karmada 란

1. CNCF 프로젝트
2. kubefed 단점 보완
3. 클러스터간 리소스 공유&배포
4. 워크로드 분산 가능
5. 정책기반 배포 및 관리가 가능
6. 클러스터간 고가용성 지원

• 기본적인 통신 플로우는 k8s 통신과 동일하게
  api서버를 기반으로 통신
  
• karmada의 컨트롤플레인이 각 클러스터의 API 서버와 통신하는 구조

1. PropagationPolicy 추가시 PolicyController가 Resource Binding 생성
2. Resource Binding 시 Binding Controller가 Manifest 를 토대로 목적 클러스터에 Execution 생성
3. Execution 생성시 Execution Controller가 목적 클러스터에 리소스를 배포

propagation policy란 
PropagationPolicy란 워크로드를 어떤 클러스터에 어떻게 분산할지 정의하는 규칙으로 멀티클러스터환경을 위해 진행되는 karmada의 핵심 개념

• ClusterAffinity: ClusterName, Label, Field에 기반 스케쥴링
• SpreadConstraint: 여러 클러스터에 고르게 분산
• ReplicasScheduling: 워크로드복제본(동일 pod)을 여러 클러스터에 어떻게(Duplicated, Wdighted, Custom) 스케쥴링할지 결정
• Toleration: 기존 k8s 스케쥴링기법을 그대로 사용

karmada 설치 방법

git clone https://github.com/karmada-io/karmada.git; karmada/hack/local-up-karmada.sh

karmada join CLUSTER_NAME --cluster-kubeconfig=/path/to/your/cluster-kubeconfig.yaml

karmada 를통해 리소스 배포 방법

placement:

    clusterAffinity:

      clusterNames:

        - member1

        - member2

를 통해서 배포할 클러스터를 정해준다 - clusterAffinity 방식 weighted 를 기준으로 분산하는데 target cluster 모두 가중치는 1로 줬기에 균등분산하여 nginx 애플리케이션을 member1,2 각각의 클러스터에 분산 배치하여 고가용성 및 부하분산 향상

pod - 컨테이너, 라벨, 노드스케쥴등으로 설정해서 컨테이너 실행, 파드에 메모리 사용량 미리 적어줄수있음. 안적어주면 문제생김 - 메모리 부족시 다른 파드의 메모리를 사용하여 애플리케이션이 불안정할거나 파드를 스케쥴링할때 마스터노드에서 얼마나 할당해야하는지 메모리 요구사항을 모르기때문에 파드가 다른 노드에 할당되지 않을수있음 마지막으로 자원 낭비

ㄴ라벨 - 키/밸류 형식의 라벨

ㄴ노드스케쥴 - 파드는 노드위에 올라가는데 노드를 직접 지정하거나 아니면 K8S 에서 자동으로 

리밋 - CPU- 낮춤, 메모리-파드 종료

서비스 - 파드는 재시작하면 아이피가 변경되기때문에 서비스 달아서 파드 연결해줘야함.

ㄴ클러스터아이피 - 외부에서는 접근안되고 클러스터 내부에서만 아이피로 접근 가능함.

ㄴ노드포트 - 클러스터아이피 기능 + 파드가 있는 노드에만 포트가 추가되는게 아니고 파드가 없는 노드까지. 모든 노드에 포트 할당함

ㄴ로드밸런서 -  앞단에서 로드밸런싱으로 파드에 접근되도록(NGINX)

볼륨 - 

EMPTY DIR - 컨테이너들끼리 데이터를 공유하기 위해 사용, 파드 생성시 같이 생성되고 지우면 같이 지워짐

HOST PATH - 경로 지정해서 사용되며 노드에 저장됨, 파드 재생성시 다른노드에 생성되면 당연히 볼륨 사용불가. 다만 노드별로 마운트해줌 사용은 가능

PV/PVC - pod > pvc > pv > volume 형식으로 연결

config map - 환경변수 (이미지 1개에 환경변수를 준다) / secret - 보안 환경변수 secret(base64)으로 설정(메모리에 저장됨)

namespace - 서비스&파드집합소, 네임스페이스끼리 공유안됨(pv등은 공유됨). 삭제하면 그안의 서비스도 전부 삭제됨

리소스쿼타 - 네임스페이스별로 리소스 쿼타 적용해서 더 올라가지 않도록 한다

리밋 레인지 - 네임스페이스별로 리소스 리밋을 적용해서 넘을경우 파드가 해당 네임스페이스에 들어가지 않도록 한다

컨트롤러 - 오토힐링, 오토스케일링, 소프트웨어업데이트, 잡등  오케스트레이션 기능들

리플리카셋 - 오토힐링,오토스케일링, 자원할당(파드할당) 기능 

탬플릿 - 탬플릿에 설정돼있는대로 오토힐링함, 이걸로 버전업그레이드 가능

replicas - 스케일인, 스케일아웃. 

셀렉터 - 파드 지정해서 실행

deployment - 파드 배포 방식

recreate - 기존 파드 삭제하고 새로운 파드 생성, 다운타임 발생

롤링 업데이트 - 기존 파드 그대로 두고 새로운 파드 생성후 기존 파드 삭제, 생성/삭제하는 시간동안 기존 파드로 접근되는 문제가 있음. 다운타임 없음.

블루/그린 - 리플리카스를 이용하여 새로운 파드 생성후 서비스를 새로운 파드로 보도록 라벨 변경. 다운타임없고 기존파드로 접근되지도 않음. 롤백도 쉬움. 가장 많이 사용

카나리 배포 - 새버전의 파드를 생성후 일부 트래픽을 새버전의 파드로 가도록하여 테스트.

데몬셋 - 모든 노드에 파드가 하나씩 생성. 프로메테우스처럼 모든 노드에 설치되야할 서비스들 설치할때 사용

잡/크론잡 - 임시로 사용할 파드들. 프로세스가 실행되지 않으면 파드 종료.(삭제되는게아님)

파드의 라이프사이클 - 파드나 컨테이너의 state 확인

서비스 - headless, endpoint, external name

ingress - 로드밸런싱이나 카나리 업그레이드 하기 위해

네트워크 - 파드네트워크와 서비스 네트워크, 실 서버의 네트워크를 다르게 줘야함.

developer commit
형상&버전관리 - gitlab

build / test / package - jenkins : gitlab에 있는 소스를 불러와서 build하고 test하고 package 한다. 단위test 통과 못하면 fail되어 개발자에게 알람. 단위테스트 통과하면 dev&prod서버에 배포 진행

정적테스트 및 분석 : 소나큐브

IaC, 빌드된 결과물을 운영환경에 배포 : ansible

운영환경 : 쿠버네티스

이런 일련의 과정을 CI/CD 파이프라인

젠킨스 설치는 도커 컴포즈로 젠킨스 플러그인 전체 설치

jenkins-item이란 : 작업(빌드,배포)최소단위

jenkins git plugin 설치

아이템별 git 레포 설정

jenkins maven plugin 설치

메이븐으로 컴파일 - clean compile package

jenkins > docker 방법

1) publish over SSH

S3란 스토리지 서비스

- 안전하고 가변적인 Object 저장공간을 제공 (ex 구글 클라우드 드라이브, 네이버 클라우드 드라이브)

- 편리한 UI 인터페이스를 통해 어디서나 쉽게 데이터를 저장하고 불러올 수 있음

- 파일 크기는 0KB부터 5TB까지 지원

- 저장공간 무제한

- Bucket 이라는 이름을 사용함(디렉토리와 유사)

- Bucket 은 보편적인 namespace를 사용 : 버킷 이름은 고유해야한다. 리전 상관없이(글로벌설정임)하나의 버킷은 모든 리전에서 고유해야함.

S3 object의 구성요소

- Key
- Value

- Version ID

- Metadata

- CORS(Cross Origin Resource Sharing) : 한 버킷의 파일을 다른 버킷에서 접근되도록 해주는 기능(리전 달라도 가능)

S3 Data Consistency Model

 - Read after Write Consistency(put) : 파일 업로드시 딜레이없이 바로 사용 가능
- Eventual Consistency(update, delete) : 버킷에 올라간 파일을 update&delete시 결과가 바로 나타나지 않는다. 다만 S3 내부에서는 적용돼있음?

S3 스토리지 타입

 - 일반 S3 : 가장 보편적으로 사용되는 스토리지 타입. 높은내구성과 가용성

 - S3 - IA(Infrequent Access) : 자주 접근되지는 않으나 빠른 접근이 요구되는 파일이 많을시 유용, 일반 S3에 비해 비용은 저렴하나 접근시 추가 비용 발생. 멀티 AZ를 통한 데이터 저장으로 가용성이 높음

 - S3 One Zone IA : 단일 AZ에 저장. 상대적으로 낮은 가용성. 데이터 접근시 S3-IA보다 20프로 비용 저렴

 - Glacier : 거의 접근하지 않을 데이터 저장시 유용. 매우 저렴한 비용. 데이터 접근시 대략 4-5시간 소요

 - Intelligent Tiering : 데이터 접근 주기가 불규칙할때 매우 유용, 2가지 티어 존재[Frequent Tier / Infrequent Tier]. 데이터 접근주기에 따라 두가지 티어중 하나로 선택됨. Frequent Tier가 비용이 더 비쌈. 최고의 비용 절감 효율을 누릴 수 있음

rds는 AWS의 RDBMS 서비스

RDS 백업의 종류

Automated Backups (자동 백업)

1. Retention period(Point in TIme) - 1~35일 안의 어떤 시간으로 돌아가게 할 수 있음

2. AB는 그날 생성된 스냅샷과 Transaction logs(TL)을 참고함

3. 디폴트로 AB기능이 설정되어 있으며 백업정보는 S3에 저장. RDS 용량 만큼만 S3 무료제공, 그 이상되면 과금

4. AB동안 약간의 I/O suspension이 존재할 수 있음 > Latency

DB snapshots (데이터베이스 스냅샷)

1. 주로 사용자에 의해 실행됨

2. 원본 RDS instance를 삭제해도 스냅샷은 존재함. 즉 스냅샷만으로도 RDS 인스턴스 복원가능

DB restore할 경우

새로운 객체가 생성됨. 

Multi AZ 

 - 원래 존재하는 RDS DB에 무언가 변화(write)가 생길 때 다른 AZ에 똑같은 복제본이 만들어짐

 - AWS에 의해 자동으로 관리가 이루어짐

 - 원본 RDS DB에 문제가 생길 시 자동으로 다른 AZ의 복제본이 사용됨

 - DR 용

 - Multi AZ는 성능 개선용이 아님. 성능 개선은 Read Replica를 써야함

Read Replicas(RR)

 - 읽기전용 복제본이 생성됨(mysql replcation이라 생각하면 됨)

 - read가 많으면 read replica 사용하면 됨( 스케일아웃가능)

 - 이건 DR용도가 아님

 - 최대 5개까지 RR 가능 - 다만 RR DB의 RR을 다시 생성가능(단 latency 발생) 이럼 무제한 ?

 - 각각의 RR은 자기만의 고유 endpoint 존재 - 아이피로 구분하지 않음

ElasticCache

 - 클라우드 내에 In-memory 캐싱디비

 - 데이터베이스에서 데이터를 읽어오는것이 아니라 캐시에서 빠른 속도로 데이터를 읽어옴

 - Read-Heavy 어플리케이션에서 상당한 Latency 감소 효과

엘라스틱캐시는 2개 타입으로 나뉨 Memcached / Redis

Memcached

 - Object 캐싱 시스템

 - Elastic cache는 Memcached의 프로토콜을 디폴트로 따름

 - 오토 스케일링 가능

 - 오픈소스

 - 단순한 캐싱 모델

Redis

 - Key-Value, set, list와 같은 형태의 데이터를 In memory 캐싱 모델

 - 오픈소스

 - Multi AZ 지원(DR 가능)

 - 리더보드처럼 데이터셋의 랭킹을 정렬하는 용도

---------실습------------

RDS 생성 - mysql 생성

1.버전 선택(디폴트)

2.탬플릿

프로덕션, 개발/테스트, 프리티어 > 선택

PS. 오로라는 프리티어 없음.

3.인스턴스 식별자 - AWS RDS 인스턴스 이름

4.마스터(root) 사용자 이름/ 암호 생성

5.DB 인스턴스 크기 > 디폴트 선택(프리티어니까)

6.스토리지 유형, 용량 > 디폴트

7.스토리지 자동조정이란 오토스케일링이고 디폴트는 활성화

8.가용성 및 내구성이란 멀티 AZ. 프리티어는 멀티 AZ 사용 못함

9.VPC 연결

10.추가 연결 구성. RDS인스턴스의 접근 허용여부. 퍼블릭 엑세스 디폴트 아니오.

11.VPC의 새로운 보안그룹 생성 해야함 ?

12. 가용영역 설정은 뭐하는거지 ? 자동설정 아니였나 ?

Read replicas 생성( 읽기전용 복제본 생성)

1.네트워크 및 보안

ㄴ완전히 다른 지역으로 복제본 생성 

ㄴ혹은 다른 서브넷 그룹

퍼블릭 액세스 (외부 공개 여부)

2.암호화 : 원본 데이터베이스를 암호화하지 않아도 RR의 암호화를 가능하게 해줌

3.모니터링 : RR의 로그 정보를 Cloud watch에 보낼지에 대한 설정

Multi AZ 

1.수정후 다중 AZ 배포 활성화(예)

EC2 요금 지불 방법

On-demand : 시간 단위로 가격이 고정되어 있음. 탄력 요금제라 생각하면 됨

Reserved : 한정된 EC2 용량 사용 가능, 1-3년동안 시간별로 할인 적용 받을 수 있음. 할당 요금제

Spot : 입찰 가격 적용, 가장 큰 할인률을 적용받으며 특히 인스턴스의 시작과 끝기간이 전혀 중요하지 않을때 매우 유용.경매방식. 실 서비스에는 쓰면 안됨

EBS란 - EC2에 부착되는 하드디스크. EC2를 사용하기 위해서는 EBS라는 디스크 볼륨이 필요

 - 저장공간이 생성되어지며 EC2 인스턴스에 부착된다.

 - 디스크 볼륨 위에 File System이 생선된다.

 - EBS는 특정 Aailability Zone에 생성된다.
AZ란 : 하나의 리전안에 여러개의 AZ가 존재하고 유사시 다른 AZ 사용가능.

EBS 볼륨타입

1.SSD군

ㄴGeneral Purpose SSD(GP2) : 최대 10K IOPS를 지원하며 1GB당 3IOPS속도. 보편적으로 사용됨
ㄴProvisioned IOPS SSD(IO1) : 극도의 I/O률을 요구(ex:매우 큰 DB관리)환경에서 주로 사용. 10K이상의 IOPS지원. 비싼만큼 속도 빠름.

2.Magnetic/HDD군

ㄴThrouhput Optimized HDD(ST1) : 빅데이터 웨어하우스, log 프로세싱에 주로 사용, Boot volume으로는 사용 불가능

ㄴCDD HDD (SC1) : 파일 서버와 같이 드문 Volume 접근시 주로 사용. Boot volume으로 사용 불가능하나 매우 저렴함

ㄴMagnetic (standard) : 디스크 1GB당 가장 쌈 . Boot volume 가능.

ELB란 Elastic Load Balancers
AWS의 로드밸런싱해줌.

Traffic의 흐름을 Unhealty instance를 healthy instance로 고가용성 제공해줌

ELB의 종류

ㄴALB : L7 로드밸런싱. http, https 로드밸런싱가능. 커스터마이징 라우팅 설정을통하여 특정 서버로 요청 보낼 수 있음
ㄴCLB : 거의 사용안하는 레거시 로드밸런싱. L4, L7 둘다 지원. 근데 사용 안함.(레거시)

ㄴNLB : L4 로드밸런싱. 매우 빠름. 극도의 퍼포먼스가 요구되는 TCP 트래픽을 처리. 

X-Forwarded-for 헤더 > 실제 아이피를 찍어주는것

Route53 : DNS 서비스

1. 도메인을 먼저 등록해주고

2. 해당 도메인들의 레코드 설정

3. 만약 도메인이 이미 있는거면 따로 등록해야 함.

-------

EC2 생성 실습

EC2는 리전 선택해야함

생성하는법 - 이건 또깡한테 듣는게 더 좋음

AWS-VPC&EC2 생성 메뉴얼

VPC(클라우드상에서 고객에게 지원되는 개인 사설 네트워크망)는 특별한경우(전혀 다른 용도의 AWS 네트워크 구성등)가 아니라면 리전별로 1개만 있으면 된다. 따라서 추가 EC2인스턴스 생성시 VPC 생성(1.AWS 네트워크 구성)은 건너뛰고 Public, Private, DB Netmask에 맞게끔 EC2를 할당

NATGW : 외부 > 내부 불가능, 내부 > 외부 가능
IGW : 외부 > 내부 가능, 내부 > 외부 가능

1. AWS 네트워크 구성
   A)VPC 생성

   

   
   B)서브넷 - 서브넷은 보통 퍼블릭, 프라이빗, DB로 나눈다.
   [퍼블릭 : bastion, NATGW, ALB|NLB]
   [프라이빗 : EC2, WEB, WAS]
   [DB : DB서버]

   

   

   
   C)IGW 생성 후 VPC에 attach

   

   
   

   

   D)EIP 2개 생성(1개는 bastion, 1개는 NATGW용도)

   

   
   E)NATGW 생성 - EIP 선택, 서브넷 선택

   

   
   F)라우팅 테이블을 설정
   ㄴ퍼블릭은 IGW로 트래픽 나가도록 라우팅
   ㄴ프라이빗,DB는 NATGW로 트래픽 나가도록 라우팅
   F-1)서브넷연결을 통해 서브넷끼리 라우팅
   ps.
   VPC 생성시 디폴트로 생성되는 라우팅 테이블은 기본 라우팅 테이블로 설정 돼 있음. 이를 새로운 라우팅 테이블을 생성한 뒤 새로 생성한 라우팅 테이블을 기본 라우팅 테이블로 변경해야만 삭제가 가능
   
    
2. EC2 생성
   
   A)bastion용 EC2 생성 - Keypair는 구글드라이브의 B/P 폴더에 보관
   B)bastion용 EC2에 EIP 연결
   C)service 용 EC2 생성
   D)앞서 생성한 ALB에 service EC2를 연결
   E)보안그룹에서 IP 허용
   F)접속 [root@proxy0 dhsa]# ssh -i Keypair-California-Bitmango.pem ec2-user@54.193.180.216
   
   
   
3. standby용으로 생성된 인스턴스들은 사용하지 않을 때 꼭 인스턴스 중지(종료가 아님, 종료시 인스턴스 삭제됨)를 해야함

   

1. 참고 내용
   base img별 ssh 계정
   ubuntu - ubuntu / centos - centos / windows - administrator / amazon linux - ec2-user
   EC2내 OS에 퍼블릭 키가 있고 그에 맞는 프라이빗 키가 발급됨 이거 잃어버리면 안됨
   
   
   

1. IAM - 유저를 관리하고 접근 레벨 및 권한에 대한 관리

1-1) Root 유저 하위의 일반 유저(A라 가정)를 생성하고 해당 유저에대한 접근키(Access key)와 비밀키(Secret Access Key)를 관리

1-2) 매우 세밀한 접근 권한 부여 기능(Granular Permission) - 회계 부서에 새로 입사한 유저 A에게 EC2의 회계 관련 서버에만 권한을 줘야함

1-3) 비밀번호를 일괄적으로 변경토록 강제 가능

1-4) 다중 인증 MFA(Multi-Factor Authentication)기능 제공

정책 - Json 형태의 document 로 돼 있음.  그룹 또는 역할에 추가 할 수 있음

역할 - 하나 혹은 다수의 정책을 추가

IAM은 regional하지 않고 global 설정임

IAM 정책 시뮬레이터 - IAM정책을 production에 빌드하기전 테스트

실습

사용자 생성

1. 엑세스 유형 - 둘다 선택도 가능
ㄴ프로그래밍 방식 엑세스 : 접근키&비밀키를 통해 접근하는 방식

ㄴAWS management console 엑세스 : 비밀번호 부여하는 방식

2. 그룹에 추가하거나 혹은 단독 유저로.

3. 액세스키와 비밀 액세스키를 확인 가능. 비밀 엑세스키의 경우 처음 한번만 확인 가능하니까 혹시 분실한다면 비밀 엑세스키 재 생성해야함.

그룹 생성

1. 그룹에 정책 추가 가능

2. 그룹에 유저 추가 가능

역할 - 다양한 정책을 부여할 수 있음. 정책과 비슷하나 유저에게 부여

정책

정책 생성에는 2가지 방법이 있다.

1. 원하는 서비스를 webUI로 선택하여 엑세스레벨을 부여할 수 있음
ㄴ리소스를 선택하는데 리소스란 다양한 기능&펑션들(백업, index등). 모든 리소스 선택

2. JSON 형식으로 엑세스 부여할 수 있음

IAM Policy Simulater 도 있음

구성

Service1.domain.co.kr 에 접속할 경우

Service1.domain.co.kr 도메인의 dns설정은 cname proxy.domain.co.kr(nginx proxy서버) 으로 해놓고

Service1.domain.co.kr > nginx proxy(nginx proxy서버) > server:service1 port(docker)

상황 : 여러 서비스에서 간헐적으로 500 Server internal Error 발생. 새로고침하면 정상화. 새로고침하면 정상화 되기에 서비스 이용에는 크게 문제가 없으나 API 이용시 500 error 발생으로 스크립트 오작동하는경우 발생.

사내 모니터링 툴인 icinga2(nagios기반)에서는 에러 발생시 1분뒤 다시한번 체크하도록 설정 돼 있기에 icinga2에서는 서비스 에러 체크가 안돼고 있었음.
다만 debug 모드에서는 500 error를 확인 할 수 있다. icinga2로그 확인시 같은시간에 여러 서비스에서 동시에 발새하는것으로 보아 어플리케이션 단일의 문제는 아닐것으로 보인다.

그럼 서비스들이 모여있는 web1, 또는 intra1 그리고 DB서버, proxy 정도의 문제로 의심해볼 수 있을듯 하다. 여기서 확인해볼 수 있는것은 최종 목적지인 web1, intra1 모든 서버에서 에러가 발생하고 있고 특히 xlsoft의 경우 디비 설정도 안돼있기에 디비 문제도 아님이 확인된다.

proxy0에 있는 munin, icinga2 는 에러가 없는것으로 보아 proxy1 서버에서 발생하는 문제라 추측하고 원인 파악할 예정

우선 접속자가 가장 적은 test.co.kr 을 모니터링 할꺼고 1.1.1.1(proxy1)과 통신을 전혀 하지 않는 standby1에서 tcpdump를 뜬다. 그래야 딱 test.co.kr 꺼만 tcpdump가 가능하니까

#!/bin/bash
function check_fnc(){
CMD=`docker exec -it compose.icinga2.test.co.kr /usr/lib/nagios/plugins/check_http -I 1.1.1.1 -S -u <https://www.test.co.kr/images/xlsoftlogo.png`>
CRI=`echo $CMD | awk '{print $2}'`
date > /etc/bin/date.txt
}

check_fnc
while [ $CRI != "CRITICAL:" ]
do
check_fnc
sleep 2
done

위 스크립트를 돌려놓기.

tcpdump 떠놓고 위 스크립트로 500 error 발생할 때까지 스크립트 돌려놓기

1) 11:24:11.764227 IP standby1.58272 > 1.1.1.1.https: Flags [S], seq 1285422234, win 29200, options [mss 1460,sackOK,TS val 2345513401 ecr 0,nop,wscale 9], length 0
2) 11:24:11.764640 IP 1.1.1.1.https > standby1.58272: Flags [S.], seq 3917766911, ack 1285422235, win 28960, options [mss 1460,sackOK,TS val 2362302169 ecr 2345513401,nop,wscale 9], length 0
3) 11:24:11.764706 IP standby1.58272 > 1.1.1.1.https: Flags [.], ack 1, win 58, options [nop,nop,TS val 2345513401 ecr 2362302169], length 0
4) 11:24:11.766695 IP standby1.58272 > 1.1.1.1.https: Flags [P.], seq 1:280, ack 1, win 58, options [nop,nop,TS val 2345513403 ecr 2362302169], length 279
5) 11:24:11.766881 IP 1.1.1.1.https > standby1.58272: Flags [.], ack 280, win 60, options [nop,nop,TS val 2362302208 ecr 2345513403], length 0
6) 11:24:11.769720 IP 1.1.1.1.https > standby1.58272: Flags [.], seq 1:5793, ack 280, win 60, options [nop,nop,TS val 2362302211 ecr 2345513403], length 5792
7) 11:24:11.769838 IP standby1.58272 > 1.1.1.1.https: Flags [.], ack 5793, win 80, options [nop,nop,TS val 2345513406 ecr 2362302211], length 0
8) 11:24:11.769977 IP 1.1.1.1.https > standby1.58272: Flags [P.], seq 5793:6028, ack 280, win 60, options [nop,nop,TS val 2362302211 ecr 2345513403], length 235
9) 11:24:11.770009 IP standby1.58272 > 1.1.1.1.https: Flags [.], ack 6028, win 86, options [nop,nop,TS val 2345513406 ecr 2362302211], length 0
1) 011:24:11.770843 IP standby1.58272 > 1.1.1.1.https: Flags [P.], seq 280:406, ack 6028, win 86, options [nop,nop,TS val 2345513407 ecr 2362302211], length 126
11) 11:24:11.800062 IP 1.1.1.1.https > standby1.58272: Flags [P.], seq 6028:6079, ack 406, win 60, options [nop,nop,TS val 2362302241 ecr 2345513407], length 51
12) 11:24:11.800284 IP standby1.58272 > 1.1.1.1.https: Flags [P.], seq 406:553, ack 6079, win 86, options [nop,nop,TS val 2345513437 ecr 2362302241], length 147
13) 11:24:11.818999 IP 1.1.1.1.https > standby1.58272: Flags [P.], seq 6079:6433, ack 553, win 62, options [nop,nop,TS val 2362302260 ecr 2345513437], length 354
14) 11:24:11.819120 IP 1.1.1.1.https > standby1.58272: Flags [FP.], seq 6433:6464, ack 553, win 62, options [nop,nop,TS val 2362302260 ecr 2345513437], length 31
15) 11:24:11.819208 IP standby1.58272 > 1.1.1.1.https: Flags [.], ack 6465, win 91, options [nop,nop,TS val 2345513456 ecr 2362302260], length 0
16) 11:24:11.819235 IP standby1.58272 > 581.1.1.1.https: Flags [F.], seq 553, ack 6465, win 91, options [nop,nop,TS val 2345513456 ecr 2362302260], length 0
17) 11:24:11.819447 IP 1.1.1.1.https > standby1.58272: Flags [.], ack 554, win 62, options [nop,nop,TS val 2362302261 ecr 2345513456], length 0

이게 500 에러일 때 tcpdump

1) 16:14:47.778543 IP standby1.42750 > 1.1.1.1.https: Flags [S], seq 387201813, win 29200, options [mss 1460,sackOK,TS val 2276549415 ecr 0,nop,wscale 9], length 0
2) 16:14:47.778893 IP 1.1.1.1.https > standby1.42750: Flags [S.], seq 1673702661, ack 387201814, win 28960, options [mss 1460,sackOK,TS val 2293338207 ecr 2276549415,nop,wscale 9], length 0
3) 16:14:47.778973 IP standby1.42750 > 1.1.1.1.https: Flags [.], ack 1, win 58, options [nop,nop,TS val 2276549415 ecr 2293338207], length 0
4) 16:14:47.781420 IP standby1.42750 > 1.1.1.1.https: Flags [P.], seq 1:280, ack 1, win 58, options [nop,nop,TS val 2276549418 ecr 2293338207], length 279
5) 16:14:47.781666 IP 1.1.1.1.https > standby1.42750: Flags [.], ack 280, win 59, options [nop,nop,TS val 2293338210 ecr 2276549418], length 0
6) 16:14:47.783826 IP 1.1.1.1.https > standby1.42750: Flags [P.], seq 1:6028, ack 280, win 59, options [nop,nop,TS val 2293338212 ecr 2276549418], length 6027
7) 16:14:47.783933 IP standby1.42750 > 1.1.1.1.https: Flags [.], ack 6028, win 81, options [nop,nop,TS val 2276549420 ecr 2293338212], length 0
8) 16:14:47.785036 IP standby1.42750 > 1.1.1.1.https: Flags [P.], seq 280:406, ack 6028, win 81, options [nop,nop,TS val 2276549421 ecr 2293338212], length 126
9) 16:14:47.785568 IP 1.1.1.1.https > standby1.42750: Flags [P.], seq 6028:6079, ack 406, win 59, options [nop,nop,TS val 2293338214 ecr 2276549421], length 51
10) 16:14:47.785670 IP standby1.42750 > 1.1.1.1.https: Flags [P.], seq 406:553, ack 6079, win 81, options [nop,nop,TS val 2276549422 ecr 2293338214], length 147
11) 16:14:47.788991 IP 1.1.1.1.https > standby1.42750: Flags [P.], seq 6079:10659, ack 553, win 61, options [nop,nop,TS val 2293338217 ecr 2276549422], length 4580
12) 16:14:47.789028 IP 1.1.1.1.https > standby1.42750: Flags [FP.], seq 10659:10690, ack 553, win 61, options [nop,nop,TS val 2293338217 ecr 2276549422], length 31
13) 16:14:47.789149 IP standby1.42750 > 1.1.1.1.https: Flags [.], ack 10659, win 99, options [nop,nop,TS val 2276549426 ecr 2293338217], length 0
14) 16:14:47.789189 IP standby1.42750 > 1.1.1.1.https: Flags [F.], seq 553, ack 10691, win 99, options [nop,nop,TS val 2276549426 ecr 2293338217], length 0
15) 16:14:47.789349 IP 1.1.1.1.https > standby1.42750: Flags [.], ack 554, win 61, options [nop,nop,TS val 2293338218 ecr 2276549426], length 0

이건 정상일 때 tcpdump

1. SYN-SENT - standby1에서 proxy1로 Syn을 보냄 : 내가(standby1) 너(proxy1)한테 접속 해도 돼 ?
2. SYN-RECEIVE - proxy1에서 syandby1한테 Syn에 대한 응답(Ack) : 너(standby1)한테 Syn 잘 받았어 (ACK) 나 준비완료, 들어와도돼 (Syn.), tcpdump에서는 Ack를 .으로 표현
3. ESTABLISHED - standby1에서 proxy1로 Ack 보냄 : 나(standby1) 랑 너(proxy1) 연결됐어 1~3까지가 3WAY 핸드쉐이크
4. SSL 핸드쉐이크 부분 - https://run-it.tistory.com/29 이거나 https://lxxyeon.tistory.com/176 이거를 4~9 까지 요거 참고
5. SSL 핸드쉐이크 부분 - https://run-it.tistory.com/29 이거나 https://lxxyeon.tistory.com/176 이거를4~9 까지 요거 참고
6. SSL 핸드쉐이크 부분 - https://run-it.tistory.com/29 이거나 https://lxxyeon.tistory.com/176 이거를4~9 까지 요거 참고
7. SSL 핸드쉐이크 부분 - https://run-it.tistory.com/29 이거나 https://lxxyeon.tistory.com/176 이거를4~9 까지 요거 참고
8. SSL 핸드쉐이크 부분 - https://run-it.tistory.com/29 이거나 https://lxxyeon.tistory.com/176 이거를4~9 까지 요거 참고
9. SSL 핸드쉐이크 부분 - https://run-it.tistory.com/29 이거나 https://lxxyeon.tistory.com/176 이거를4~9 까지 요거 참고
10. SSL 암호화된 데이터 전송 https OK
11. SSL 암호화된 데이터 전송 https OK
12. FIN_WAIT1 - proxy1에서 standby1한테 접속 끊자는(FIN) 패킷 발송 : 나(proxy1)는 너(standby1)한테 볼일 다 봤어. 이제 끊자(FIN)
13. CLOSE_WAIT - standby1이 proxy1한테 Fin에 대한 응답(Ack) : 그럴래 ? 잠깐만~ 너가 볼일 다본 프로세스 종료준비좀 할께. 기다려봐
14. LAST_ACK - standby1이 proxy1한테 FIN 패킷 발송 : 나(standby1)는 프로세스 종료할 준비 됐어 ~ 너 준비 됐어 ?
15. TIME_WAIT - proxy1이 standby1한테 종료에 대한 응답 .(ACK) 발송 : 응. 나 끊었어
    끝

정상 / 비정상과 딱히 차이 없음.

비정상일때 패킷2개가 더 있긴한데 이거는 SSL 통신할 때 인증서 확인을 한패킷에서 했냐 한번 나눴냐 차이. 즉 패킷이 끊기는건 없다. 따라서 timeout은 아니라는 말.
ㄴ간헐적 장애는 거의 대부분이 timeout문제(경험)임. 네트워크랑 앤드포인트나 애플리케이션단 타임아웃이 서로 달라서 발생하는등. 근데 이 문제는 타임아웃 문제 아님. 그럼 백프로 nginx proxy서버문제가 맞다고 보여진다.

nginx proxy 에러로그를 다시한번 살펴보면..

에러 발생한 시간에 bind(0.0.0.0) failed (98: Address already in use) while connecting to upstream, 이게 찍혀있다. 포트 중복되는 문제로 많이 보던 에러라 보고서 누가 포트 잘못 올렸나 하고 넘어갔떤건데... 이제보니 포트가 안찍혀있다.
그리고 생각해보면 포트 중복문제면 nginx 재시작등 서비스 올라올 때 포트 중복되면 찍혀야 하는건데 이건 라이브중에 찍힌 에러.. 이 에러가 문제가 맞는것으로 보인다.

혹시나 icinga2에서 에러 발생한 시간에 맞춰보니 전부 그시간에 위 에러가 찍혀있다. 물론 icinga2는 체크를 실시간으로 하는게 아니니까 백프로 일치하진 않지만 nginx에 찍힌 에러 로그안에 아이싱가 로그 시간을 포함하고 있다.

bind(0.0.0.0) failed (98: Address already in use) while connecting to upstream 이처럼 포트가 안찍히는 경우는 해당 서버가 클라이언트입장에서 서버로 로그인 할 때 클라이언트 포트가 이미 사용중이라 해당 에러가 발생할 수 있다. > nginx proxy가 실서비스(도커의 :28080)

[root@proxy1 ~]# cat /proc/sys/net/ipv4/ip_local_port_range

1024 65535

[root@proxy1 nginx]# netstat -an |grep TIME_WAIT | grep -v 1.1.1.1:443 | grep -v 1.1.1.1:80 | awk '{print $4}'| awk -F ":" '{print $2}' | sort -n | head

1024

1025

1026

1027

1030

[root@proxy1 nginx]# netstat -an |grep TIME_WAIT | grep -v 1.1.1.1:443 | grep -v 1.1.1.1:80 | awk '{print $4}'| awk -F ":" '{print $2}' | sort -n | tail

65524

65525

65528

65529

65535

[root@proxy1 nginx]# netstat -an |grep TIME_WAIT | grep -v 1.1.1.1:443 | grep -v 1.1.1.1:80 | wc -l 44562

실제로 클라이언트 포트를 1024부터 뛰엄뛰엄 65535까지 상당히 많이 쓰고 있지만 이론상으로 현재 문제는 발생하면 안된다.(6만개도 안넘었으니까)

[root@proxy1 log]# cat /home/var/proxy1.datawave.co.kr/logs/error.log | grep 'Address already in use' | awk '{print $2}' | awk -F ":" '{print $1":"$2}' | sort | uniq -c | sort -rn | head -n 100

10743 05:29

10472 05:28

10092 05:43

10070 06:29

8481 05:51

8263 05:49

8252 05:48 중략

6081 05:26

6065 05:08

새벽 5~6시에 집중돼있음

netstat -an 카운트 새벽에 계속 돌렸을 때 몇개까지 차는지 보면 이게 원인인지 아닌지 확인 할 수 있음

만약 클라이언트 포트 고갈 문제가 맞다면

log3의 8080(fastlog)와 통신을 가장 많이하는데 이거 1회성 연결로 끊지말고 1시간에 한번씩 연결해서 작업하던가 하는 식으로 바꾸는게 바람짐학

서버에서 해줄 수 잇는 작업은 리싸이클 커널 파라미터 조정해야 할 듯 한데(그 외 커널 파라미터는 최적화 돼 있는 상태임)

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=nkyle9361&logNo=220060056557

근데 위 설정 해주면 fin 안받고 세션 끊고 바로 배정하는거라 킵얼라이브처럼 세션 재활용할 때 500 에러 난다고 하니 위 설정은 하면 안될 듯 - 위 본문에도 있듯이 Client쪽이 방화벽 또는 NAT 환경일 때<< 프록시 서버라 문제 날 수 있을것같음.

아마존 - AWS, 구글 - GCP, 마소 - Azure 와 같이 이미 구축되어진 클라우드 시스템을 이용하는것이 퍼블릭 클라우드라면관리자가 직접 프라이빗 클라우드 시스템을 구축할 수 있게끔 해주는 오픈소스 프로젝트가 openstack이다. 
(국내에 Openstack으로 클라우드 서비스를 제공하는 업체도 있다고 한다.)

## tcpdump

yum install tcpdump


eth0 전부 캡쳐 

tcpdump -i eth0


지정수만큼 캡쳐

tcpdump -c 5 -i eth0


아스키형식 캡쳐

tcpdump -A -i eth0


캡쳐가능 인터페이스 확인

tcpdump -D


헥사와 아스키형식 캡쳐

tcpdump -XX -i eth0


캡쳐 파일 저장 

tcpdump -w file.txt -i eth0


저장파일 읽기

tcpdump -r file.txt

tcpdump -Xqnr


IP 주소만 캡쳐 

tcpdump -n -i eth0


특정포트 캡쳐

tcpdump -i eth0 port 22


소스 IP 캡쳐

tcpdump -i eth0 src 192.168.0.2


목적지 IP 캡쳐

tcpdump -i eth0 dst 1.116.66.139


TCP만 캡쳐

tcpdump -i eth0 tcp


응용

tcpdump -w tcpdump_ssh22.txt -s 1500 tcp port 21 and host 211.x.x.x

기존 사내 업무 환경이 기존에는 구글 엑셀을 통해 업무를 많이 봤는데 최근에 rdbms를 통한 업무가 상당히 많아졌다.기존에도 rdbms를 쓰긴 했지만(사내 디비 환경은 도커 컨테이너 기반의 master+slave 환경으로 서비스를 하고 있었다.) 웹+디비등의 환경에서만 쓰였는데 최근에는 대부분의 임직원이 디비를 활용하여 업무를 하고 있다.

어쨌든 업무환경이 디비를 통한 업무가 증가하면서 기존에는 원활하게 돌아가던 DB(mariadb)가 원인불명의 다운이 발생한다. 아마 사용량이 많아지면서 잘못된 사용?이 있었거나.. 여튼 원인을 파악해야 하기에 모니터링 툴을 찾아봤고 pmm 이 나왔다.

pmm 이란 페르소나 모니터링 엔드 메니지먼트로 여러 오픈소스 디비의 모니터링을 지원(오라클은 지원X)하고 있다. 클라우드 디비들까지.

pmm은 클라이언트-서버로 구성 돼 있다. 클라이언트에서 수집된 데이터들을 서버로 보내면 서버에서 웹UI를 통한 대시보드, 그래프등으로 표시된다.

PMM 서버는 쿼리 분석을 위한 [QAN API, QAN web app] / DB저장 및 시각화하기 위한[그라파나, 프로메테우스, 클릭하우스]로 이루어져 있고 이것들로 유저는 PMM 서버의 엔진엑스/pgsql을 통해 웹 UI제공/설정저장이 가능하다.

PMM 클라이언트는  pmm-admin 과 pmm-agent, db-expoter로 이루어져있고 클라이언트의 데이터를 수집하고 서버로 전송하기위한 과정들을 할 수 있게끔 한다.

즉 쉽게 설명하자면

pmm 모니터링을 하기 위해서는 3가지가 필요하다.

pmm 서버 / pmm 클라이언트 / 수집대상 데이터베이스

pmm 서버는 당연히 아무곳에나 해도 되고 pmm 클라이언트도 아무곳에나 해도된다. 꼭 수집대상 데이터베이스에 안해도 된다. 

따라서 나같은 경우는 pmm서버/클라이언트를 한곳에 설치해줬다. 클라이언트라길래 꼭 수집대상 데이터베이스가 있는 서버내에 설치해야하나 헷갈렸어서 적어준다. 물론 데이터베이스 있는 서버에 설치해주면 서버의 리소스까지도 모니터링이 되는 이점은 있다.

설치 진행

현재 인프라 운영환경이 전부 도커 컨테이너 기반이기 떄문에 설치도 도커(도커 컴포즈)를 통해 진행할꺼고 순서는 다음과 같다.

1. 모니터링 호스트 서버에 PMM-server를 도커컴포즈로 설치하고
2. PMM-client가 디비에서 데이터 수집을 할 수 있도록 디비 계정 생성 및 추가 설정 진행 해주고
3. 디비 컨테이너가 있는 도커 컴포즈에 PMM-client를 추가하고

4. 

1. 모니터링 호스트 서버에 PMM-server 설치

version: '2'

services:
  pmm-data:
    image: percona/pmm-server:latest
    container_name: pmm-data
    volumes:
      - ./prometheus/data:/opt/prometheus/data
      - ./consul-data:/opt/consul-data
      - ./mysql:/var/lib/mysql
      - ./grafana:/var/lib/grafana
    entrypoint: /bin/true

  pmm-server:
    image: percona/pmm-server:latest
    container_name: pmm-server
    ports:
      - '11180:80'
    restart: always
    environment:
      - SERVER_USER=admin
      - SERVER_PASSWORD=pmmadmin
      - METRICS_RETENTION=720h
      - METRICS_MEMORY=4194304
      - METRICS_RESOLUTION=1s
      - QUERIES_RETENTION=30
    volumes_from:
      - pmm-data

docker-compose up -d 하고 웹으로 접속하면 초기 아이디/패스워드는 admin/admin 인것같다. 컴포즈에서 설정하는건 적용이 안되는것으로 보임 기본 아이디 패스워드는 admin/admin 이다. 패스워드는 로그인 한 뒤 패스워드 변경해야 하고 변경된 상태로 컨테이너 스탑 한 뒤 컨테이너 이미지를 새로 만들어야 한다.(각종 설정정보는 위에 기술한것처럼 pmm-server 내 pgsql에 저장 되는데 pgsql은 컴포즈 설정상 바인딩마운트를 하지 않기 때문에 도커 컴포즈 재시작하면 설정 다 날라간다. 그래서 초기 설정한 뒤 이미지 새로 떠놓던가 아니면 pgsql도 바인딩 마운트 추가하던가 해야함)

2. 수집할 데이터가 있는 디비에 pmm-client가 접근할 수 있도록 계정 생성 및 데이터 권한 추가

MariaDB [(none)]> create user 'pmm'@'192.168.226.%' identified by '패스워드';
Query OK, 0 rows affected (0.001 sec)
MariaDB [(none)]> grant select, process, replication client, reload on *.* to 'pmm'@'192.168.226.%';
Query OK, 0 rows affected (0.001 sec)

3. pmm-client가 디비서버에서 쿼리데이터를 수집 할 때 슬로우쿼리/퍼포먼스스키마 둘중 하나에서 수집하는데 뭘로할지 정해야함.

아래 설명 보는것처럼 슬로우쿼리는 디테일한 정보(즉 더 많은 정보)를 볼 수 있지만 시스템 성능에 영향을 줄 수 있고 로그 용량 관리등을 해줘야 한다. 반면 퍼포먼스 스키마에서 가져올 경우 디테일하지 않다는 단점만 있다. 일단 퍼포먼스 스키마로 설정해주고 내가 필요한 데이터(즉 현재 다운되는 원인을 파악 할 수 있는 데이터)가 없다면 슬로우 쿼리로그로 바꾸는게 맞을것같은데...

그러나 현재 디비 구성이 퍼포먼스 스키마는off이고 슬로우 쿼리가 on이다. 
우선 퍼포먼스 스키마/슬로우 쿼리에 대해 좀 더 알아볼 필요가 있겠다. 슬로우쿼리는 우리가 지정한 타임 이상 걸린 쿼리에 대한 정보를 남기는것이고 퍼포먼스스키마에 대한 설명:http://cloudrain21.com/everything-of-mysql-performance-schema 

말 그대로 성능에 대한 정보가 담긴 디비(스키마)라고 생각하면 됨.

정리하자면 
슬로우쿼리 : 내가 설정해둔 시간보다 많이 걸리는 쿼리들 로깅 됨
퍼포먼스 스키마 : 여러 수집 가능한 정보들이 있는데 항목별로 on/off하여 수집 가능
앞서 PMM에서 알려준(슬로우쿼리가 좀 더 디테일한 장점이 있고 반대로 퍼포먼스스키마는 정보가 많지 않다는 단점이 있다는) 것과 반대로 디비 운영 관점에서 보자면 슬로우쿼리(슬로우쿼리에 쌓이는 데이터들은 단순히 어떤 쿼리가 느렸는지 정도만 파악 가능)보다 퍼포먼스 스키마가 더 많은(더 디테일한)정보를 볼 수 있다고 이해가 된다. 

근데 왜 PMM에서는 슬로우쿼리가 좀 더 디테일하다고 설명하는걸까 ? 슬로우쿼리 안에 데이터로 뭐가 분석이 되나...? 이부분 이해가 안가는데... 단순히 슬로우 쿼리는 쿼리 전체가 다 찍히니... 그래서 디테일 하다는건가 ? 일단 설치해보고 슬로우쿼리/퍼포먼스스키마 각각 수집되는 항목들 직접 보고 비교해봐야겠다.

아래와 같이 performance_chema를 on등을 설정해주고 mysql을 재시작한다.
performance_schema=ON
performance-schema-instrument='statement/%=ON'
performance-schema-consumer-statements-digest=ON
innodb_monitor_enable=all
#query_response_time_stats=ON   ###이건 mysql에 플러그인 추가로 설치해줘야 한다. 
userstat=ON

퍼포먼스 스키마 실행 확인 완료

퍼포먼스 스키마DB에 데이터가 쌓이고 있음도 확인

4. pmm-client install

https://docs.percona.com/percona-monitoring-and-management/details/commands/pmm-agent.html 참고하였다.

우선 아래의 내용으로 docker-compose.yaml 생성
version: '2'
services:
  pmm-client:
    image: percona/pmm-client:2
    hostname: pmm-client-myhost
    container_name: pmm-client
    restart: always
    ports:
      - "42000:42000"
      - "42001:42001"
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "5"
    volumes:
      - ./pmm-agent.yaml:/etc/pmm-agent.yaml
      - pmm-client-data:/srv
    environment:
      - PMM_AGENT_CONFIG_FILE=/etc/pmm-agent.yaml
      - PMM_AGENT_SERVER_USERNAME=admin
      - PMM_AGENT_SERVER_PASSWORD=admin
      - PMM_AGENT_SERVER_ADDRESS=X.X.X.X:443
      - PMM_AGENT_SERVER_INSECURE_TLS=true
    entrypoint: pmm-agent setup
volumes:
  pmm-client-data:

      - PMM_AGENT_SERVER_ADDRESS=X.X.X.X:443
    hostname: pmm-client-myhost
위 두개를 수정해준다

그리고 콘피그 파일 touch pmm-agent.yaml && chmod 0666 pmm-agent.yaml 수정 될 수 있또록 생성/권한 수정 해주고

docker-comose up(설정파일 생성을 위해 임시로 실행하는것임)해주면 아래와 같이 pmm-agent.yaml이라는 설정파일이 생성된다.

여기서 중요한점 두가지
첫번째는 해당 설정파일에는 인증정보가 있으니 외부로 노출하면 안되고 두번째는  docker-compose.yaml 에서 수정했던
    hostname: pmm-client-myhost
위 부분을 각 사용자에 맞게 수정을 해줘야 그에 맞춰서 pmm setup 명령어를 통해 agent.yaml이 생성된다. 만약 hostname을 기존에 쓰던 네임일 경우 agent 설정파일이 생성되지 않는다.
agent.yaml 생성 됐으면 마지막으로 다시한번 도커 컴포즈 야믈파일에서     entrypoint: pmm-agent setup 이부분 주석하고 다시한번 마지막으로 docker-compose up -d 으로 실행해주면 컨테이너가 잘 실행 될것이다.pmm-agent.yaml 파일에 데이터가 씌어져 있어야 한다.

여기서 발생한 에러 

위와같이 pmm.mycompanydomain.co.kr로 연결이 안됨.

원인 : pmm-client가 pmm-server로 연결 할 때 pmm.mycompanydomain.co.kr 주소로 연결하는데 
회사 구성은 도메인 연결시 nginx.proxy 구성이 돼 있기에 pmm.mycompanydomain.co.kr:443 은 nginx proxy 로 intra.mycompany.co.kr:11443으로 포워딩 해주고 있는데
https://forums.percona.com/t/pmm-agent-can-not-connect-to-pmm-server-when-using-reverse-proxy/8435/10
이 과정에서 문제가 있었던것 같고 그냥 intra.마이콤파니닷컴 명시해주었다.

마지막으로 pmm.url.com 대쉬보드로 접속해서 

아까 pmm 계정 생성했던(즉 모니터링 할 디비)서버 정보 입력해주고 몇분 기다려보면 아래와같이 데이터가 수집된다.

모니터링 하는 방법은

그래프 쌓아서 보다보면 이건 쫌 이상한데 ? 싶은 튀거나 이가 빠지는 그런 그래프가 있을꺼다. 딱봐도 수상해보이는 그래프들이 있을꺼니까 

위와 같이 해당 그래프의 panel json을 들어가보면 

각 그래프들의 설명을 자세하게 적어줬다. 심지어 URL까지.

/ 디렉토리 용량이 많이 차서 원인이 뭔지 확인하려고 du -sch ./* 이런 명령어 입력하면

별도로 파티셔닝했떤 /home 디렉토리도 같이 용량 체크하느라 시간이 오래걸리는경우가 있다. 이 외에도 du 후 exclude 폴더가 절실할때가 많았다. 몇번 찾아보기도 했었는데 분명 안나왔었고...  그래서 매번 du -sch ./a* du -sch ./b*  이런식으로 찾다가... 

이참에 exclude 옵션을 추가하여 du 명령어를 더 보완해보자 라는 마음으로 du exclude 구글링 검색을 해봤는데..

아래와 같이 du 에서 --exclude 옵션이 있었다... 예전에 내가 검색을 잘 못했던것 같다....

du -sch ./* | grep -v 폴더 이런식의 방법만 나와서 시간 오래걸리는건 매한가지로 똑같았는데 분명... 이상하다. 여튼 du 에도 exclude 옵션이 있다.

목표 : isms 관점에서 법령에 맞게끔 DB로깅을 하고 분석을 한다.
필요 로그정보 : "누가,언제,어디서,무엇을,어떻게" 의 5개 정도 나오면 된다고 본다.

general로그에는 모든 쿼리가 전부 쌓이고 있으니 확인이 가능하지만 general 로그 용량이 너무 커져서 select query는 안남도록 하고싶다.

확인해보니 select을 제외한 트랜잭션이 발생한 쿼리만 로깅하는게 바이너리로그다. (알고 있었는데 까먹었었다.)

바이너리로그를 보는법은 mysqlbinlog bin로고ㅡ파일명 > filename.sql 확인 가능하다 허나 bin log에는 ISMS에서 필요로 하는 누가와 어디서가 나오지 않는다. 따라서 isms의 개인정보처리시스템에 대한 로그는 general로그를 보관하는게 맞다.

내가 쓰고도 이글의 요지가 뭔지 모르겠는데... 이글을 처음 쓰게된 이유(목표)는 general로그 용량이 워낙 크니 select 쿼리는 빼자였는데... isms 관점에서는 빼면 안되는거였다. 애초에 생각을 깊이 하지 않아서 이런 똥글이 나왔다.

Jul 11 03:37:14 db1 systemd: Created slice libcontainer_16098_systemd_test_default.slice.
Jul 11 03:37:14 db1 systemd: Removed slice libcontainer_16098_systemd_test_default.slice.
Jul 11 03:37:14 db1 systemd: Scope libcontainer-16126-systemd-test-default-dependencies.scope has no PIDs. Refusing.
Jul 11 03:37:14 db1 systemd: Scope libcontainer-16126-systemd-test-default-dependencies.scope has no PIDs. Refusing.
Jul 11 03:37:14 db1 systemd: Created slice libcontainer_16126_systemd_test_default.slice.
Jul 11 03:37:14 db1 systemd: Removed slice libcontainer_16126_systemd_test_default.slice.
Jul 11 03:37:14 db1 systemd: Scope libcontainer-16153-systemd-test-default-dependencies.scope has no PIDs. Refusing.
Jul 11 03:37:14 db1 systemd: Scope libcontainer-16153-systemd-test-default-dependencies.scope has no PIDs. Refusing.
Jul 11 03:37:14 db1 systemd: Created slice libcontainer_16153_systemd_test_default.slice.
Jul 11 03:37:14 db1 systemd: Removed slice libcontainer_16153_systemd_test_default.slice.
Jul 11 03:37:15 db1 systemd: Scope libcontainer-16180-systemd-test-default-dependencies.scope has no PIDs. Refusing.
Jul 11 03:37:15 db1 systemd: Scope libcontainer-16180-systemd-test-default-dependencies.scope has no PIDs. Refusing.
Jul 11 03:37:15 db1 systemd: Created slice libcontainer_16180_systemd_test_default.slice.
Jul 11 03:37:15 db1 systemd: Removed slice libcontainer_16180_systemd_test_default.slice.
Jul 11 03:37:15 db1 systemd: Scope libcontainer-16207-systemd-test-default-dependencies.scope has no PIDs. Refusing.
Jul 11 03:37:15 db1 systemd: Scope libcontainer-16207-systemd-test-default-dependencies.scope has no PIDs. Refusing.
Jul 11 03:37:15 db1 systemd: Created slice libcontainer_16207_systemd_test_default.slice.

위와같은 에러가 message 로그에 대량(초당 3~4회씩반복)으로 남고있어, 메세지로그확인이 상당히 어렵다.

하여 아래와 같이 원인 분석 및 조치를 진행했다.

1. 해당 로그가 쌓이는 원인 파악
https://github.com/kubernetes/kubernetes/issues/71887

https://github.com/moby/moby/issues/30628

위 내용들을 종합해보자면 docker 의 native cgroup driver를 native.cgroupdriver=systemd 으로 사용하고 있는데 

systemd에 의해 잘 실행 되는지 컨테이너 런타임(runC)이 잘 실행되는지 확인하기 위한 일시적인 테스트라고 한다.
테스트로 컨테이너를 생성하는데 pid가 없으니까 생성/삭제하는건가... 이 이상으로 설명이 돼 있는건 구글링해도 찾을수가없었다.

여튼 해당 메세지 자체가 있다고해서 서버나 운영환경에 문제를 야기할껀 아니라고 판단된되니 로그를 안쌓도록 하면 될것같다.

2. 해당 로그를 안쌓도록 하는 방법

근본적으로 도커 컨테이너에서 설정을통해 안쌓도록 하고 싶지만 구글링시 안나오고 있다. 따라서 rsyslog에서 해당 로그는 쌓이지 않도록 설정한다.

[root@db1 rsyslog.d]# pwd
/etc/rsyslog.d
[root@db1 rsyslog.d]#
[root@db1 rsyslog.d]#
[root@db1 rsyslog.d]# cat ignore-container-log.conf
if ($programname == "systemd") and ($msg contains "_systemd_test_default.slice" or$msg contains "systemd-test-default-dependencies.scope") then {
  stop
}

위와 같이 rsyslog.d 에 ignore 설정파일 하나 만들어서 메세지 같으면 안쌓이도록 설정 

벤포드의 법칙이란걸 접했다. 상당히 흥미가 갔다. 내가 하는 업무가 빅데이터를 다루기도 하고… 데이터 검증을 해야 하기도 하니….상당히 흥미가 갔다.
도입부 설명이 아래와 같았다.
1~100만의 숫자중 랜덤으로 100만번 선택했을 경우 골라진 숫자의 맨 첫자리 숫자가 1일 확률이 가장 높고 그다음이 2.. 3…
이게 실제로 적용되는지 스크립트로 짜서 돌려봤다. 

굉장히 신기했다. 이게 말이 돼 ? 랜덤으로 뽑는건데 ? 실제로 적용되는지 궁금했다.

-MacBookPro benford % cat sss.sh

#!/bin/sh

num=1

while [ $num -le 1000000 ]

do

random_num="$(($RANDOM% 9999+1))"

first_num="${random_num:0:1}"

echo "$first_num" >> 123123.txt

((num++))

done

랜덤함수가 32767 까지밖에 안나오니 1부터 9999까지 랜덤으로 뽑도록 해보고… 결과는 아래와 같다.

MacBookPro benford % cat 123123.txt | sort | uniq -c

135337 1

128771 2

105152 3

105292 4

105207 5

105114 6

105024 7

105305 8

104798 9

1이랑 2가 많긴 하지만…이건 벤포드의 법칙보다는 내가 뭔가 간과한 부분이 있는것같다. 어쨌든 벤포드의 법칙을 설명할 때 적잖은 유튜버, 블로거들이 했던 설명인"1~100만의 숫자중 랜덤으로 100만번 선택했을 경우 골라진 숫자의 맨 첫자리 숫자가 1일 확률이 가장 높고" 은 잘못된 예제같다. 일단 패스.

벤포드의 법칙이 적용되려면 광범위한 데이터여야 하고 비선형의구조를 보이는? 데이터여야 한다고 한다.(정확히 이해한건지 모르겠다..)
그럼 진짜로 이게 실 데이터에 적용되는지… 실제 회사내의 데이터를 가지고 확인해보았다.

약 200 개 앱(게임)들의 365일간의 일일 매출들. 즉 약 7만개(200개 앱 * 365일)데이터가 벤포드 법칙에 적용이 되는지 확인해보았다.

결과는

MacBookPro benford % awk '{print $2}' benford.txt| sort | uniq -c

14610 1 (33프로) 

8585 2 (18프로) 

4893 3 (10프로) 

4447 4 (9.6프로) 

3479 5 (7.5프로) 

3013 6 (6.5프로)

2116 7 (4.6프로)

1870 8 (4프로)

2002 9 (4.3프로)

null값이나 오입력된 값(0 입력)등도 있어서 퍼센티지가 100이 되진 않는다.

이정도면 상당히 적용된다고 볼수 있다. 신기하다… 근데 9로 시작하는게 많네… 벤포드 법칙에 따르면 9로 시작하는 값들중 오입력된 값들이 많다는 뜻이겠다. 또한 1로 시작하는게 실제 벤포드의 법칙보다는 수치가 살짝 높고 그렇다. 

9로 시작하는 값들을 먼저 봐볼까..

MacBookPro benford % cat benford.txt| awk '{ if ($2==9) print $1}' |  sort -n | uniq -c  | sort -rn | more
 189 9.99
 135 9.98
  28 9.97
  25 9.95
  11 9.96
   6 9.9
   6 9.2161
   4 9.94
   4 9.59

9.99 가 굉장히 수상하다.

        "d250": 9.99,
        "d251": 1.99,
        "d252": 15.99,
        "d253": null,
        "d254": 4.99,
        "d255": 4.99,
        "d256": 9.99,
        "d257": null,
        "d258": 3.98,
        "d259": 9.99,
        "d260": 8.98,
        "d261": 19.97,
        "d262": 1.99,
        "d263": 14.97,
        "d264": 9.99,

위와같이 1.99 2.99 9.99 등 오입력된 값들이 많음을 실제로도 볼 수 있었다. 왜 오입력이 됐는지는 개발자들에게 문의를 해야할것이고 ... 매출이 n.99 가 나올 가능성이 얼마 안될 듯 한데... 저것들 다 오입력된것같다. 그중 1.99나 2.99 등은 워낙 분포가 많으니 티가 안났겠지만 9의 경우 분포가 작으니 이렇게 티가 나는듯 ? 

여튼 데이터가 잘못된것을 찾아냈다. 상당히 유의미하다. 
처음 접했을땐 말이되나 ? 신기하다. 였는데  벤포드의 법칙에 대해서 위키등 설명을 더 자세히 읽어보니 이런 데이터가 나오는게 수긍이간다. 1 > 2로 가려면 2배 2 > 3은 1.5배 3 > 4는 1.3배....  점점 진입하기가 쉬워지기 때문이다.

흠..이걸 실제 데이터 검증에 쓸 수 있는 방법은 없을까 ? 서버 파일들의 용량을 점검한다면 ?

#!/bin/sh
ls -latr /bin/ | grep -v lrwx | awk '{print $5}' > /root/sss.txt
num=`cat /root/sss.txt`
for i in $num; do
first_num="${i:0:1}"
echo "$i $first_num" >> benford1.txt
done
awk '{print $2}' benford1.txt | sort | uniq -c

위와 같이 /bin/ 디렉토리내 파일들의 용량도 벤포드의 법칙이 적용된다. 변조여부 확인하는데 참고정도는 할 수 있을지도 ?

고객 요청에 의한 단일노드 설치나 테스트로 CRUD까지만 해봤는데 이번에 실무에서 처음으로 mongodb 구축 및 관리를 진행하게 됐다.
따라서 SE 관점에서 구성전 알아야 할 것, 설치방법, 백업&모니터링등 관리 노하우, 장애 대처법정도 메뉴얼로 정리해본다.

상황
GCP firebase realtimeDB 를 사용하고 있었는데 월 천만원정도 나오던게 월 2천만원이 발생하였다. firebase의 경우 데이터를 쓰는데는 금액이 무료(저장공간에 대한 비용은 발생)지만 다운로드 한 크기(즉 쿼리가 실행에 대한 응답, read)에 대해 비용이 발생한다. 따라서 수시로 데이터를 read 해야 한다면 ? (예를들어 실시간으로 랭킹이 바뀌는.) 비용이 어마어마하게 나올것이다.(나왔다.)

비용에 대한 압박때문에 개발자가 맘편히 개발을 못하는 환경은 좋지 못하다고 판단하여 realtimeDB를 사내 IDC에 자체 구축한 DB로 옮기기로 하였고 그에 따라 mongodb를 구축하기로 하였다. nosql 인지도 1등, 기존에 사용하기도 했었기에.

구축전 알아야 할 것
1. mysql / mongodb 용어 차이

2.스키마 설계시 고려사항 - 우리는 설치까지만하고 이후부터는 개발자가 하겠지만 그래도 알면 나쁠거 없으니 쓰윽 읽어보면 좋을듯

1.도큐먼트의 최대 크기는 16MB

2.쿼리 및 쓰기의 접근 패턴
가장 일반적인(빈도가 가장 많은)쿼리와 함께 쿼리되는 데이터가 동일한 도큐먼트에 저장되도록 설계하고 이러한 쿼리(앞서 말한 일반적인 쿼리)에 사용되지 않는 데이터나 자주 사용하지 않는 데이터는 다른 컬렉션에 넣자.
동적(읽기/쓰기)-정적(대부분 읽기)데이터 분리 여부도 고려

3.cardinality
도큐먼트와 데이터의 관계가 one to (few,many,squilions) 을 고려 - https://m.blog.naver.com/heops79/221649719470 참고 

4.스키마 설계 패턴 - 개발자에게 패턴을 추천해주면 좋을듯
다형성 패턴 - 
속성 패턴 - 
버킷 패턴 - 
이상치 패턴 - 
계산된 패턴 - 
서브셋 패턴 - 
확장된 참조 패턴 - 
근사 패턴 - 
트리 패턴 - 
사전 할당 패턴 - 
도큐먼트 버전 관리 패턴 - 

5.정규화 vs 비정규화 
일반적으로 정규화(데이터를 여러 컬렉션에)는 쓰기가 빠르고 비정규화(모든 데이터를 하나의 도큐먼트에)는 읽기가 빠르다.

6.오래된 데이터 제거
제한 컬렉션 사용 - 오래된 데이터가 밀려나는 방식, 급격히 증가하는 트래픽에 안좋음
TTL 컬레션 사용 - 294페이지
주기마다 컬렉션 삭제 - 여러개의 컬렉션을 사용(rotate 방식이라 생각하면될듯) - 컬렉션네임을 동적으로 사용ㅎ애 여러 데이터베이스를 조회하기에 구축하기에 복잡
7.데이터베이스와 컬렉션 설계시 고려사항
- 스키마가 유사한 도큐먼트는 같은 컬렉션에

이제부터가 se 영역

mongodb 구성은 보통 3가지로 진행한다.
단일 - 테스트용도

replica set - 일반적으로 사용됨
샤딩 - 대용량 고사양 필요시

여기서는 replica set을 구성했고 각각 다른 3개의 서버에 각각의 mongodb 컨테이너를 실행해서 프라이머리(P)세컨(S)세컨(S)pss 방식으로 리플리카셋 구성(하나의 서버에 컨테이너 실행할때도 동일하게 하되 바인딩포트만 바꾸면됨)

1.각각의 서버에 mongodb 실행

compose.yaml 파일 내용

version: "3"
services:
  devmongo.test.co.kr:
    image: docker.bitmango.com/mongodb.test.co.kr:2021_10_5
    restart: always
    container_name: devmongo.test.co.kr
    ports:
      - "28017:27017"
    volumes:
      - ./data/db:/data/db
    entrypoint: [ "/usr/bin/mongod", "--bind_ip_all", "--replSet", "replication", "-f", "/etc/mongod.conf", "--journal", "--dbpath", "/data/db", "--enableMajorityReadConcern", "false" ]

이미지 안에는 mongodb 4점대 latest기본 이미지 파일에 

관리자계정 생성한다음 (생성하느건 구글링 많음)

[root@db1 mongore.datawave.co.kr]# cat mongod.conf
# mongod.conf
security:
  keyFile: "/etc/mongodb.key"
  clusterAuthMode: "keyFile"
  authorization: "enabled"

/etc/mongodb.key 파일 들어가있고 key파일 들어가있는걸 컨테이너 커밋한거고 생성하는건 아래처럼

출처: https://appledog.tistory.com/entry/MongoDB-Replica-Set-설정 [김군이다 (머리가 나쁘면 적어!)]

2.리플리카셋 구성 

한서버에서만 아래 입력(아마 입력하는곳이 프라이머리가 되는것같음?)

> var config = {
... _id: "replication",
... members: [
... {_id: 0, host: "db1.test.co.kr:28017"},
... {_id: 1, host: "db2.test.co.kr:28017"},
... {_id: 2, host: "db3.test.co.kr:28017"}
... ]
... };

이러면 리플리카셋 구성 끝.

3. 실제 사용자에게 제공할 유저&디비 생성하기
replication:PRIMARY> use 2222222
replication:PRIMARY> db.createUser({ user: "2222222", pwd:"1111111", roles: ["readWrite"]})

위처럼 생성할 디비 를 use 디비명 해주고 거기서 createUser 해주면 됩니다.


접속은

mongodb://222222:*****@db1.test.co.kr,db2.test.co.kr,db3.test.co.kr:28017/?authSource=222222&replicaSet=replication&readPreference=nearest&appname=MongoDB%20Compass&ssl=false

위와같이...

이중에 readPreference 옵션은(https://rastalion.me/mongodb-replica-set-%EC%84%B8%EB%B6%80-%EC%84%A4%EC%A0%95%EA%B0%92-%EC%A1%B0%EC%A0%95%ED%95%98%EA%B8%B0/참고)

• primary: 기본값이며, Primary 구성원으로부터 값을 읽고 오며, 딜레이 없이 데이터 수정 및 삽입 작업이 가능합니다.
• primaryPreferred: Primary 구성원으로부터 우선적으로 데이터를 읽어옵니다. 특별히 Primary 쪽의 읽기 작업이 밀려있지 않으면 Primaey에서 데이터를 가져오기 때문에 변경사항을 바로 확인 할 수 있습니다. 읽기가 밀려 있는 상태라면 Secondary에서 데이터를 읽어옵니다.
• secondary: 모든 읽기 작업을 Secondary 에서 처리합니다.
• secondaryPreferred: 우선적으로 읽기 작업이 발생하면 Secondary에 작업을 요청합니다. 하지만 모든 Secondary에서 작업이 밀려 있는 경우 Primary에 읽기 작업을 요청합니다.
• nearest: 해당 구성원이 Primary인지 Secondary인지에 관계없이 네트워크 대기 시간이 가장 짧은 복제본 세트의 구성원에서 읽기 작업을 합니다.

•  
•  

  mongo "mongodb://mongodb0.example.com.local:27017,mongodb1.example.com.local:27017,mongodb2.example.com.local:27017/?replicaSet=replA&ssl=true"

자주 사용하는 명령어
rs.conf() - rs설정 확인
rs.isMaster() - rs 프라이머리 확인
use dbname
db.createCollection("[COLLECTION_NAME]") - collection 생성
rs.slaveOk() - slave 에서 쿼리하고싶을때
db.getUsers() - DB에 연결된 유저 리스트 확인

db.createUser({ user: "USERNAME", pwd: "PASSWORD", roles: [ "readWrite" ]})

db.auth("아이디", "패스워드")

빌트인돼있는 주요 디비 권한들

read

readWrite

참고 책
몽고디비 완벽가이드3판-크리스티나초도로

참고 사이트
https://edu.goorm.io/learn/lecture/557/%ED%95%9C-%EB%88%88%EC%97%90-%EB%81%9D%EB%82%B4%EB%8A%94-node-js/lesson/174384/mongodb%EB%9E%80

윈도우에서 슬랙 메세지 보내기

상황 : 윈도우에 누군가 로그인 할 때마다 슬랙으로 메세지를 받고자 한다.

작업스케쥴러에 로그인시 특정프로그램(슬랙메세지프로그램)실행되도록 하면 될듯.

작업스케쥴러 설정하는건 구글링하면 많이 나온다. 근데 윈도우에서 슬랙메세지 보내는건 잘 안나온다. 리눅스처럼 curl 명령어로 해봐도 에러가 난다. 그래서 파워쉘모듈중 psslack 이라는 파워쉘-슬랙 모듈을 사용해본다.

https://github.com/RamblingCookieMonster/PSSlack

여기서 import-module psslack 할 때 에러난다.

나의 경우는 권한문제로 에러가 발생했고 파워쉘 실행할 때 관리자권한으로 실행해주고

execution policy 입력시 결과가 restricted 라면 set execution-policy unrestricted 로 해준 뒤 임폴트-모듈 psslack 하면 잘 된다.

도커깃랩 초기패스워드 old 버전은 5ive 이런식으로 돼 있었는데 최근에는 깃랩 컨테이너내 콘피그 디렉토리에 랜덤으로 생성된다.

root@gitlab:/# cat /etc/gitlab/initial_root_password  | grep Pass
#          2. Password hasn't been changed manually, either via UI or via command line.
Password: IDGRN4k2+KTTAyjylr2WPupfmxB7hy4nPzRDzPPQqGs=

정상적으로 잘 운영되던 gitlab 서비스가 간헐적으로 500error를 뿜는다.
(도커로 운영중)
결론부터 말하자면 /dev/shm 용량이 부족함

해결한 방법은 아래

간헐적인 에러가(에러를 500으로 한정하지 않고) 발생한다는건 경험상으로

1.네임서버 변경시 전파가 제대로 안돼서 정상호스트/비정상호스트 번갈아가면서 가질 때

2.용량이 가득 찼을 때

3.서버내 리소스 가득 찼을 때(트래픽 등, ip conttrack등)

4.원래는 계속 에러나야하는데 정상으로 온 응답에 캐쉬가 남아있어서 정상/비정상 간헐적으로 나온다고 느끼는경우

등이 있을 수 있겠다.

이번 gitlab 간헐적 500 error 처리한 방법은 아래와 같다.

네임서버 변경작업을 요 근래 해서 혹시 실수가 있었나 싶어 체크했으나 문제 없음
서버내 용량 확인 했으나 여유 많음
서버 부하 전혀 없음
간헐적으로 발생하는것 맞음(화요일 아침 출근하고 약 7시간 정상 서비스 운영됨)

gitlab-ctl status tail 하는데 로그가 너~~~무 많이 나와서 확인 불가

gitlab 로그 디렉토리 가서 보는데 엔진엑스 에러로그는 안찍히고.. 그외에 같이 올라오는 서비스가 너무 많아서 뭘 봐야 할지 감이 안옴

서버내 message 로그 보니 
7250550 Aug 17 16:29:57 intra1 journal: writing value to /dev/shm/gitlab/puma/histogram_puma_master-1.db failed with unmapped file
7250551 Aug 17 16:29:57 intra1 journal: writing value to /dev/shm/gitlab/puma/histogram_puma_master-1.db failed with unmapped file
7250552 Aug 17 16:29:57 intra1 journal: writing value to /dev/shm/gitlab/puma/histogram_puma_master-1.db failed with unmapped file
7250553 Aug 17 16:29:57 intra1 journal: writing value to /dev/shm/gitlab/puma/histogram_puma_master-1.db failed with unmapped file
7250554 Aug 17 16:29:57 intra1 journal: writing value to /dev/shm/gitlab/puma/histogram_puma_22-1.db failed with unmapped file
7250555 Aug 17 16:29:57 intra1 journal: writing value to /dev/shm/gitlab/puma/histogram_puma_22-1.db failed with unmapped file
7250556 Aug 17 16:29:57 intra1 journal: writing value to /dev/shm/gitlab/puma/histogram_puma_22-1.db failed with unmapped file
7250557 Aug 17 16:29:57 intra1 journal: writing value to /dev/shm/gitlab/puma/histogram_puma_22-1.db failed with unmapped file
7250558 Aug 17 16:29:57 intra1 journal: writing value to /dev/shm/gitlab/puma/histogram_puma_22-1.db failed with unmapped file

/dev/shm 에 매핑이 안된다?
df -h 해서 다시 자세히 보니 /dev/shm쪽에 100프로 가득찬게 있었다.
shm                           64M   64M  0M   100% /home/docker/containers/156031a474f3b85b848c3c7e45ce190559fac145851f123b71e4b3670105b823/shm
[root@intra1 log]# docker ps | grep git
156031a474f3        gitlab/gitlab-ee:13.0.10-ee.0                             "/assets/wrapper"        18 minutes ago      Up 18 minutes (healthy)   0.0.0.0:22->22/tcp, 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp           compose.gitlab.sdfsf.com

컨테이너 아이디 보니까 깃랩.

13     ports: [
 14       "443:443",
 15       "80:80",
 16       "22:22"
 17     ]
 18     #image: gitlab/gitlab-ce:13.0.0-ce.0
 19     image: gitlab/gitlab-ee:13.0.10-ee.0
 20     shm_size: '512mb'

위와같이 shm 사이즈 512로 늘려주고 컴포즈 재시작하고 조치 완료

재택근무가 길어짐에따라 site to client 의 SSL-VPN 구성이 필요해졌다.

직원별로 접속 계정을 하나하나 생성할수도 없는노릇이고. 내가 지금 다니는 회사는 구글 워크스페이스로 업무를 하고 있다. 따라서 Single sign on 기능으로 구글 워크스페이스와 연동해보려한다.

fortigate 100E의 SSL-VPN 설정 화면이다. 설정하기에 앞서 간략히 SSL-VPN에 대해 설명을 하자면

SSL 프로토콜을 이용하여 VPN을 구성하는데. 클라이언트(즉 재택하는 직원)는 별도의 프로그램이 필요 없고 웹 브라우저만 있으면 VPN 접속을 할 수 있기에 굉장히 편리하다. 

SSL-VPN portals 는 클라이언트가 SSL-VPN으로 연결되어 보여질 웹페이지의 레이아웃과 사용자에게 할당 될 IP 대역을 설정하는 메뉴이다.
web-access mode : 포티장비가