_zero_.log

WSL2 설치

Tue, 14 Mar 2023 05:01:07 GMT

1. WSL 설치

OS 버전 확인
- window + R → winver 입력 → 20H1 버전 이상인지 확인

WSL 설치
- cmd에서 명령어 실행
- Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

2. version2 변환

파워쉘 관리자 권한 실행
- 명령어 실행
- dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
- dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

재부팅

파워쉘 관리자 권한 실행
- 명령어 실행
- wsl --set-default-version 2

윈도우용 리눅스 커널 설치(링크)

3. 이미지 다운로드

window + S → microsoft store 입력 → 원하는 리눅스 이미지 검색 → 다운로드

4. WSL 명령어

WSL 목록 확인 wsl -l
상세 정보 확인 wsl -l -v
WSL 종료 wsl -t [wsl_name]

5. 참고

AWS Private subnet에 ALB 구성

Mon, 06 Mar 2023 14:41:49 GMT

1. 구성도

2. 대상 그룹(Target Group) 생성

EC2 > 대상 그룹 > 대상 그룹 생성
- 유형 인스턴스
- 대상(Private 인스턴스) 선택

3. ALB 생성

EC2 > 로드밸런서 > 로드밸런서 생성
- 기본구성
- 네트워크 맵핑
- 리스너

4. 참고

https://www.inflearn.com/course/aws-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EB%B3%B8

AWS Bastion Host 및 NAT Gateway 구성

Thu, 02 Mar 2023 15:38:37 GMT

1. 구성도

2. Private subnet EC2 생성

EC2 > 인스턴스 > 인스턴스 생성
- Bastion Host 접속용 키페어 생성
- Private subnet 설정 및 퍼블릭 IP 비활성화

3. Private subnet EC2 접속

Public EC2 접속 후
- Bastion Host 접속용 키페어를 .pem 확장자로 복사
- pem 파일 권한 수정 chmod 400 key.pem
- Private EC2 접속 ssh -i key.pem [user_name]@[private_ec2_ip]

4. NAT Gateway 구성

VPC > NAT 게이트웨이 > NAT 게이트웨이 생성
- 이름, 서브넷, EIP 등 설정
라우팅 테이블 설정
- Private subnet 라우팅 테이블에 NAT GW 추가
- NAT GW 구성 후 Private EC2에서 인터넷 통신 테스트

5. 참고

https://www.inflearn.com/course/aws-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EB%B3%B8

AWS ALB를 통한 이중화 구성

Wed, 01 Mar 2023 12:45:33 GMT

1. 구성도

2. Target Group 생성

EC2 > 대상그룹 > 대상그룹 생성
- 그룹 세부 정보 지정
- 대상 등록

3. ALB 구성

EC2 > 로드밸런서 > 로드밸런서 생성
ALB 생성 확인
ALB 작동 확인

4. 참고

https://www.inflearn.com/course/aws-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EB%B3%B8

AWS EFS 파일시스템 구성

Wed, 01 Mar 2023 11:56:44 GMT

1. 구성도

2. EFS 통신을 위한 SG 생성

EC2 > 보안 그룹 > EFS용 SG 생성(인스턴스에 적용된 SG를 인바운드 SRC로 설정)

3. EFS 구성

EFS > 파일 시스템 생성 > 사용자 지정
- 파일 시스템 설정(사용 목적에 따라 옵션을 다르게 설정 가능)
- 네트워크 액세스(퍼블릭 서브넷과 EFS SG 설정)

4. 인스턴스에 EFS 마운트

인스턴스 설정
- EFS 유틸 설치 yum install amazon-efs-utils -y
- EFS 마운트 경로에 디렉터리 생성 mkdir /var/www/html/efs
EFS 연결
- DNS를 통한 탑재 > EFS 탑재 핼퍼 복사
- 인스턴스에서 명령어 실행
EFS 작동 테스트
- 파일 다운
- 브라우저 접근 확인

5. EFS 작동 확인

다른 인스턴스에 동일한 EFS 마운트
앞서 다운받은 파일이 존재하는지 확인

6. 참고

https://www.inflearn.com/course/aws-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EB%B3%B8

AWS 커스텀 AMI 생성

Wed, 01 Mar 2023 09:02:36 GMT

1. 커스텀 AMI 생성

EC2 > 인스턴스 > AMI를 생성할 인스턴스 선택 > 작업 > 이미지 및 템플릿 > 이미지 생성
이미지 정보 설정

2. 커스텀 AMI를 활용한 인스턴스 배포

인스턴스 생성 시 커스텀 AMI 선택

AWS에 APM 웹서버 구성

Wed, 01 Mar 2023 08:44:01 GMT

1. 구성도

2. 인스턴스 배포

EC2 > 인스턴스 > 인스턴스 시작

인스턴스 이름 설정
AMI 설정
인스턴스 유형 설정
키 페어 설정(기존에 사용하던 키 페어가 없을 경우 생성)
네트워크 설정
SG 설정
스토리지 설정

사용자 데이터 설정(아래 배시 입력)

    #!/bin/bash
    yum update -y
    amazon-linux-extras install -y lamp-mariadb10.2-php7.2 php7.2
    yum install -y httpd mariadb-server
    systemctl start httpd
    systemctl enable httpd
    usermod -a -G apache ec2-user
    chown -R ec2-user:apache /var/www
    chmod 2775 /var/www
    find /var/www -type d -exec chmod 2775 {} \;
    find /var/www -type f -exec chmod 0664 {} \;

Elastic IP 부여
- 탄력적 IP > 탄력적 IP 주소 할당 > 할당
- EIP 선택 > 작업 > EIP 주소 연결 > 인스턴스 설정 > 연결

3. 인스턴스 접속

putty, xshell 등 터미널 도구를 활용해 인스턴스의 EIP로 접속

4. 웹서버 접근

브라우저에서 인스턴스의 EIP로 정상 접근 확인

5. 참고

https://www.inflearn.com/course/aws-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EB%B3%B8

1분만에 AWS 기본 네트워크 구성

Wed, 01 Mar 2023 08:01:22 GMT

1. 구성도

2. VPC / Subnet / Internet Gateway / Route Table 생성

VPC > VPC 생성 > VPC 등 선택
- VPC 설정 입력
- AZ 설정 입력
- 서브넷 설정 입력
- DNS 설정
- 설정 결과 확인

3. 참고

https://www.inflearn.com/course/aws-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EB%B3%B8

S3와 CloudFront를 활용한 정적 웹사이트 호스팅

Wed, 01 Mar 2023 06:47:34 GMT

1. 구성도

1.1. S3를 활용한 구성

1.2. S3 + CloudFront를 활용한 구성

2. S3 정적 웹사이트 구성

S3 생성
- S3 > 버킷 만들기 > 버킷 이름과 리전 설정 > 버킷 만들기(속도 테스트를 위해 대한민국과 지리적으로 먼 임의의 해외 리전 선택)
- 생성한 버킷에 파일 업로드
S3 호스팅 기능 활성화
- S3 > 속성 > 정적 웹 사이트 호스팅 편집 > 활성화 > 인덱스 문서 설정 > 변경사항 저장
- 버킷 엔드포인트로 접근 시 403 확인
버킷 접근권한 설정
- S3 > 권한 > 퍼블릭 액세스 차단(버킷 설정) 편집 > 모든 퍼블릭 액세스 차단 체크 해제 > 변경 사항 저장

오브젝트 접근권한 설정

S3 > 권한 > 버킷 정책 편집 > 아래 정책 붙여넣기 > 변경 사항 저장

{
"Id": "Policy1677651198477",
"Version": "2012-10-17",
"Statement": [
{
  "Sid": "Stmt1677651196313",
  "Action": [
    "s3:GetObject"
  ],
  "Effect": "Allow",
  "Resource": "버킷 ARN 입력/*",
  "Principal": "*"
}
]
}

버킷 엔드포인트 정상 접근 확인

3. CloudFront 추가 구성

CloudFront 생성
- CloudFront > CloudFront 배포 생성 > 원본 도메인에 정적 호스팅용 버킷 선택 > 웹 사이트 엔드포인트 사용 > 배포 생성
- 배포 도메인을 통해 접근 확인

4. S3 vs CloudFront 속도 비교

S3
- S3로만 서빙할 경우 5초 ~ 9초 소요

CloudFront
- CloudFront를 구성하는 경우 1초 ~ 2초 소요

5. 참고

https://www.inflearn.com/course/aws-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EB%B3%B8

쿠버네티스 Blue·Green / Canary 배포 방법

Thu, 02 Feb 2023 16:09:49 GMT

1. 개념

Blue·Green 및 Canary 배포 전략에 대한 개념은 앞서 작성한 글 참고
Blue·Green 배포 : Blue 리소스를 구성하고 Selector로 서비스와 맵핑한 상태에서 Green 리소스를 구성하고 서비스의 Selector를 Green으로 변경
Canary 배포 : v1과 v2 리소스를 구성하고 두 리소스를 Selector로 서비스와 맵핑한 상태에서 v2의 레플리카 개수를 점진적으로 증가시킴과 동시에 v1의 개수를 감소시키다 마지막에는 v1 리소스 삭제

2. Blue·Green 배포

Blue에 해당하는 nginx 웹서버 리소스 구성

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
apiVersion: apps/v1
kind: Deployment
metadata:
  name: resource-blue
  namespace: default
spec:
  replicas: 5
  selector:
    matchLabels:
      app: resource-blue
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: resource-blue
    spec:
      containers:
      - image: nginx
        name: nginx
      restartPolicy: Always
cs

서비스 생성 및 selector를 통해 Blue 리소스와 맵핑

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: v1
kind: Service
metadata:
  name: blue-green
spec:
  ports:
  - name: "80"
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: resource-blue
  type: NodePort
cs

Blue 리소스 서비스 접근 테스트

Green에 해당하는 아파치 웹서버 리소스 구성

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
apiVersion: apps/v1
kind: Deployment
metadata:
  name: resource-green
  namespace: default
spec:
  replicas: 5
  selector:
    matchLabels:
      app: resource-green
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: resource-green
    spec:
      containers:
      - image: httpd
        name: httpd
      restartPolicy: Always
cs

서비스의 selector를 Green 리소스와 맵핑
Green 리소스 서비스 접근 테스트

3. Canary 배포

v1 리소스 생성

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
apiVersion: apps/v1
kind: Deployment
metadata:
  name: canary-v1
  namespace: default
spec:
  replicas: 5
  selector:
    matchLabels:
      app: canary
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: canary
    spec:
      containers:
      - image: nginx
        name: nginx
      restartPolicy: Always
cs

v2 리소스 생성

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
apiVersion: apps/v1
kind: Deployment
metadata:
  name: canary-v2
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: canary
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: canary
    spec:
      containers:
      - image: httpd
        name: httpd
      restartPolicy: Always
cs

서비스 생성 및 selector를 통해 v1과 v2 리소스를 서비스에 맵핑

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: v1
kind: Service
metadata:
  name: svc-canary
spec:
  ports:
  - name: "80"
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: canary
  type: NodePort
cs

서비스 접근 테스트(현재 5:1 비율)
v2 레플리카 증가 및 v1 레플리카 감소 및 서비스 접근 테스트(현재 1:5 비율)
v1 리소스 삭제

4. 참고

https://www.udemy.com/course/certified-kubernetes-application-developer/

쿠버네티스 Custom Resource 개념 및 설정

Mon, 30 Jan 2023 15:25:05 GMT

1. 개념

디플로이먼트, 레플리카셋 등 기본적으로 정의된 리소스 외에 Custom Resource를 활용하여 관리자가 원하는 리소스를 정의하고 사용 가능

2. Custom Resource 생성

crd 생성

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: internals.datasets.kodekloud.com
spec:
  group: datasets.kodekloud.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                internalLoad:
                  type: string
                range:
                  type: integer
                percentage:
                  type: string
  scope: Namespaced
  names:
    plural: internals
    singular: internal
    kind: Internal
    shortNames:
    - int
Colored by Color Scripter
cs

.metadata.name : crd의 이름. plural+group의 조합으로 구성
.spec.group : API 이름
.spec.versions.name : API 버전
.spec.versions.schema.openAPIV3Schema.properties.spec.properties : crd에서 요구하는 값
.spec.scope : crd 적용 범위. Namespaced 또는 Cluster
.spec.names.plural : URL로 호출 시 사용할 alias
.spec.names.singular : CLI로 핸들링 시 사용할 alias
.spec.names.kind : crd 매니페스트 생성 시 기입할 kind. 일반적으로 singular를 카멜케이스 형식으로 작성
.spec.names.shortNames : crd의 단축어

3. Custom Resource 사용

생성한 crd에 맞춰 리소스 생성
1
2
3
4
5
6
7
8
9
kind: Internal
apiVersion: datasets.kodekloud.com/v1
metadata:
  name: crd-test-internal
  namespace: default
spec:
  internalLoad: "high"
  range: 80
  percentage: "50"
cs
- .apiVersion : .spec.group/.spec.versions.name
- .spec : .spec.versions.schema.openAPIV3Schema.properties.spec.properties에 정의한 값

4. Custom Resource 핸들링

k get crd : Custom Resource 목록 확인
k describe crd [crd_name] : Custom Resource 세부 정보 확인
k delete crd [crd_name] : Custom Resource 삭제
k get [shortNames] : crd를 통해 생성한 리소스 확인

5. 참고

쿠버네티스 Admission Controller(Mutating / Validating) 개념 및 설정

Sat, 28 Jan 2023 13:45:20 GMT

1. 개념

쿠버네티스에서 파드 등의 리소스를 생성하는 경우 접근권한은 3단계를 거치게 됨
- Authentication(인증) → Authorization(인가) → Admission Control
인증·인가에서는 인가된 사용자인지, 적절한 권한이 있는지를 확인함
Admission Control은 인가되고 권한을 보유한 이용자의 액션에 대해 관리자가 정의한 설정을 적용하도록 강제함
Admission Control로 핸들링이 가능한 액션(플러그인)은 링크에서 확인 가능

2. Admission Controller 예시

kube-api의 --enable-admission-plugins에 NamespaceAutoProvision 설정
ns 목록 확인
존재하지 않는 ns에 파드 생성
자동으로 ns가 생성 및 파드가 생성됨을 확인

3. Mutating / Validating

Admission Controller의 세부 동작 단계로서 Mutating이 먼저 수행되고 그 다음 Validating을 수행
- Mutating : API 요청을 검사해 관리자가 정의한 규칙에 어긋나는 경우 요청 내용을 수정
- Validating : API 요청의 유효성을 검사하여 요청을 거절 또는 승인

4. 참고

쿠버네티스 Statefulset 개념 및 설정

Thu, 26 Jan 2023 15:49:34 GMT

1. 개념

파드에 저장된 데이터 또는 파드의 설정을 stateful하게 유지해야 하는 경우 Statefulset 활용
Statefulset으로 생성한 파드는 재생성 시에도 랜덤한 문자열 이름이 아닌 관리자가 정의한 특정 규칙의 이름으로 생성
Statefulset으로 생성한 파드의 스토리지는 PVC로만 연결 가능
Statefulset에 접근하기 위해서는 headless service 생성 필요

2. Statefulset 생성

headless service 생성

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: v1
kind: Service
metadata:
  name: headless-svc
  labels:
    app: headless-svc
spec:
  ports:
  - name: http
    port: 80
  clusterIP: None
  selector:
    app: test-sts
cs

statefulset 생성

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: test-sts
spec:
  selector:
    matchLabels:
      app: test-sts
  serviceName: headless-svc
  replicas: 3
  template:
    metadata:
      labels:
        app: test-sts
    spec:
      containers:
      - name: zero
        image: nginx
        ports:
        - containerPort: 8080
cs

3. statefulset 확인

파드의 이름이 랜덤한 문자열이 아닌 statefulset 생성 시 설정한 test-sts-n 형식으로 생성
sts의 파드가 삭제되어도 순차적으로 삭제
headless 서비스를 통해 sts 파드 접근

4. 참고

쿠버네티스 Job, CronJob 개념 및 설정

Tue, 17 Jan 2023 15:51:17 GMT

1. 개념

특정 작업을 수행하기 위한 목적으로 사용하는 오브젝트로, 특정 액션을 수행하는 임시 파드 정도로 생각하면 적절
주기적으로 특정 액션을 수행해야 할 경우 cronjob을 사용

2. Job, CronJob 설정

Job

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4
Colored by Color Scripter
cs

CronJob

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox:1.28
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure
cs

3. 세부 옵션

.spec.completions : 몇개의 job이 complete되어야 완료된 것인지 정의
.spec.parallelism : 최초에 병렬적으로 생성할 job의 개수
.spec.backoffLimit : job의 작업이 실패할 경우에 재시도할 횟수
.spec.activeDeadlineSeconds : job이 시작된 후 작동 가능한 유효 시간
.spec.template.spec.restartPolicy : 에러 발생 시 재시작 옵션
- Always : 항상 재시작
- OnFailure : 장애 발생 시 재시작
- Never : 재시작하지 않음

4. 참고

쿠버네티스 Probe(Readiness, Liveness, Startup) 개념 및 설정

Mon, 16 Jan 2023 15:26:06 GMT

1. Probe 개념

1.1. Readiness, Startup

파드의 상태를 체크 할 수 있는 2가지의 지표가 존재
- get을 통해 확인 가능한 STATUS 정보
- describe을 통해 확인 가능한 Conditions 정보
STATUS와 Conditions이 Running/True 상태임에도 불구하고 컨테이너가 초기화 프로세스(cold start)를 거치는 경우 파드에 정상적으로 접근 불가
컨테이너 생성 및 HTTP 요청에 대한 응답을 할 수 있는지 확인하기 위해 Readiness Probe를 활용
컨테이너에 배포된 서비스의 초기화 프로세스(cold start)가 완료되어 서비스를 제공할 수 있는지 확인하기 위해 Startup Probe를 활용
1.2. Liveness
파드에 장애가 발생하는 경우 k8s 특성상 파드를 재생성 및 삭제함
하지만 파드 자체에는 문제가 없으나 컨테이너에 장애가 발생한 경우 파드는 복구되지 않고 접근이 불가능한 상태로 지속적으로 존재하게 됨
이러한 문제를 해결하기 위해 Liveness Probe를 활용
Liveness Probe를 설정할 경우 지속적으로 컨테이너의 상태를 체크하고 비정상일 경우 파드를 재생성
1.3. 한줄 요약
probe는 컨테이너의 상태를 확인하기 위한 기능

2. Probe 핸들러

컨테이너의 상태를 확인하는 주체는 kubelet이며, kubelet은 핸들러를 활용해 컨테이너의 상태를 확인
3종류의 핸들러 존재
- HttpGetAction : 지정된 포트와 URL로 HTTP Get 요청을 전송해 응답 코드가 200 ~ 400 구간인 경우 성공 이외의 경우 실패
  1
  2
  3
    httpGet:
      path: /healthcheck
      port: probeport
  cs
- ExecAction : 컨테이너에서 관리자가 지정한 명령어를 실행. 명령어 상태 코드가 0일 경우 성공 이외의 경우 실패
  1
  2
  3
  4
    exec:
      command:
      - cat
      - /tmp/healthy
  cs
- TCPAction : 지정된 포트로 TCP 소켓 연결 시도. 연결 성공 시 성공
  1
  2
  tcpSocket:
  port: 8080
  cs

3. Probe 옵션

Probe 설정을 세밀하게 조정하기 위한 옵션이 존재
세부 내용은 공식 문서 참고

4. Probe 설정

Readiness, Liveness, Startup Probe 모두 설정 방법은 동일하며 probe 이름만 수정 필요

HTTP Probe 설정

1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: v1
kind: Pod
metadata:
  name: readinessTest
spec:
  containers:
  - name: nginx
    image: nginx
    readinessProbe:
      httpGet:
        path: /healthcheck
        port: 8080
cs

exec Probe 설정

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: v1
kind: Pod
metadata:
  name: readinessTest
spec:
  containers:
  - name: nginx
    image: nginx
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
cs

TCP Probe 설정

1
2
3
4
5
6
7
8
9
10
11
apiVersion: v1
kind: Pod
metadata:
  name: readinessTest
spec:
  containers:
  - name: nginx
    image: nginx
    readinessProbe:
      tcpSocket:
        port: 8080
cs

5. 참고

AWS에 ELK 스택 구축(7.x)

Sat, 07 Jan 2023 06:44:51 GMT

1. ELK 스택 개념

beats
- 일종의 에이전트 역할로서 로그를 수집하고자 하는 서버에 설치
- 단순히 로그를 수집해서 output(전송)하는 역할
logstash
- ELK 서버 또는 클러스터에 설치
- beats로 부터 수신한 로그를 관리자가 원하는 형태로 재가공해서 es로 전송하는 역할
elasticsearch
- ELK 서버 또는 클러스터에 설치
- 대용량의 로그를 저장하고 검색하는 역할
kibana
- ELK 서버 또는 클러스터에 설치
- 수집한 로그를 다양하게 시각화해서 대시보드로 보여주는 역할

2. 구성도

3. ELK 스택 구축

3.1. ELK 인스턴스 생성

OS : Ubuntu 20.04 LTS 64bit x86
type : ELK가 메모리를 많이 요구하기 때문에 최소 t2.medium 이상

3.2. Elasticsearch 설치

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
# java 설치
sudo apt-get update
sudo apt install openjdk-11-jdk
 
# 설치
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg
sudo apt-get install apt-transport-https
echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-7.x.list
sudo apt-get update && sudo apt-get install elasticsearch
 
# 메모리 수정
sudo vi /etc/elasticsearch/jvm.options
-Xms256m
-Xmx256m
 
# 설정 수정
vi /etc/elasticsearch/elasticsearch.yml
node.name: node-1
network.host: 0.0.0.0
http.port: 9200
discovery.seed_hosts: ["127.0.0.1"]
cluster.initial_master_nodes: ["node-1"]
 
# 서비스 등록 및 시작
sudo /bin/systemctl daemon-reload
sudo /bin/systemctl enable elasticsearch.service
sudo systemctl start elasticsearch.service
curl -X GET "localhost:9200"
 
# 상태 확인
curl localhost:9200/_cat/indices?v
curl -X GET localhost:9200/_cat/health?v
curl -X GET localhost:9200/_cat/nodes?v
Colored by Color Scripter
cs

3.3. Kibana 설치

1
2
3
4
5
6
7
8
9
10
11
12
13
# 설치
sudo apt-get update && sudo apt-get install kibana
 
# 설정 변경
vi /etc/kibana/kibana.yml
server.port: 5601
server.host: "0.0.0.0"
elasticsearch.hosts: ["http://[es_ip]:9200"]
 
# 서비스 등록 및 시작
sudo /bin/systemctl daemon-reload
sudo /bin/systemctl enable kibana.service
sudo systemctl start kibana.service
cs

3.4. Logstash 설치

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# 설치
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list
sudo apt-get update && sudo apt-get install logstash
 
# 설정
vi /etc/logstash/conf.d/logstash.conf
input {
  beats {
    port => 5044
    host => "0.0.0.0"
  }
}
 
filter {
 
}
 
output {
  elasticsearch {
    hosts => ["http://localhost:9200"]
    index => "%{[@metadata][beat]}-%{[@metadata][version]}-%{+YYYY.MM.dd}"
    #user => "elastic"
    #password => "changeme"
  }
}
 
# 서비스 등록 및 시작
sudo /bin/systemctl daemon-reload
sudo /bin/systemctl enable logstash.service
sudo systemctl start logstash.service
 
# 상태 확인
tail -f /var/log/logstash/logstash-plain.log
Colored by Color Scripter
cs

3.5. 모니터링 대상 인스턴스에 Filebeat 설치

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# 설치
curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.17.8-amd64.deb
sudo dpkg -i filebeat-7.17.8-amd64.deb
 
# 설정 변경
vi /etc/filebeat/filebeat.yml
- type: log
  id: test_log
  enabled: true
  paths:
    - /var/log/*.log
 
filebeat.config.modules:
  path: ${path.config}/modules.d/*.yml
  reload.enabled: true
 
setup.dashboards.enabled: true
setup.kibana:
  host: "[kibana_ip]:5601"
 
output.logstash:
  hosts: ["es_ip:5044"]
 
# 모듈 설정
filebeat modules list
filebeat modules enable [모듈]
 
# 서비스 등록 및 시작
sudo /bin/systemctl daemon-reload
sudo /bin/systemctl enable filebeat.service
sudo systemctl start filebeat.service
Colored by Color Scripter
cs

4. Elasticsearch / Kibana 인증 설정

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# 서비스 중지
sudo systemctl stop elasticsearch.service
sudo systemctl stop kibana.service
sudo systemctl stop logstash.service
 
# es 설정 추가
sudo vi /etc/elasticsearch/elasticsearch.yml
xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
 
# es 서비스 실행
sudo systemctl start elasticsearch.service
 
# 패스워드 설정 
sudo /usr/share/elasticsearch/bin/elasticsearch-setup-passwords interactive
 
# kibana 설정 수정
sudo vi /etc/kibana/kibana.yml
elasticsearch.username: "elastic"
elasticsearch.password: "설정한 패스워드"
 
# kibana 서비스 실행
sudo systemctl start kibana.service
 
# logstash 설정 추가 
sudo vi /etc/logstash/conf.d/logstash.conf
output {
  elasticsearch {
    user => "elastic"
    password => "설정한 패스워드"
  }
}
 
# logstash 서비스 실행
sudo systemctl start logstash.service
Colored by Color Scripter
cs

5. AWS SG 설정

ELK 인스턴스 SG에 다음의 인바운드 규칙 추가
- src : 모니터링 대상 인스턴스 또는 any / port : 5044 / proto : tcp
- src : kibana 접근을 허용하고자 하는 IP / port : 5601 / proto : tcp
- src : es 접근을 허용하고자 하는 IP 또는 any / port : 9200 / proto : tcp

6. ELK 동작 확인

"ELK 인스턴스 공인IP:5601" 접속 후 id : elastic / pass : 설정한 비밀번호 입력
왼쪽 메뉴 → Discover 클릭

7. 참고

Certified Kubernetes Administrator(CKA) 자격증 취득 후기(22.12. 시험)

Sun, 11 Dec 2022 15:05:42 GMT

1. 취득 계기

MSA가 대세아닌 대세가 된 현 시점에서 K8s는 산업계 표준이라고 해도 무방할 정도로 현업 깊숙이 자리잡고 있습니다.
따라서 보안 엔지니어 입장에서 보안적인 측면을 이해하고 적용을 요청하기 위해 자의반 타의반으로 공부를 시작하게 되었는데요.
네트워크 엔지니어로 커리어를 시작해서인지 공부하는 과정이 상당히 즐거웠고 재밌었네요.
앞으로 남은 CKAD와 CKS까지 천천히 공부하려고 목표를 잡고 있는데 벌써부터 설레는 마음입니다.
취득 기간은 하루에 최소 1시간씩 주 4~5일씩 공부했고 총 6개월이 소요됐습니다. 파드랑 노드가 뭔지도 모르는 제로 베이스에서 시작한 것 치고는 적절한 시간이라고 생각해봅니다. ㅎㅎ

2. 공부 방법

1. 강의

쿠버네티스에 대해 아무것도 모르는 상태였기 때문에 한글로 설명된 초보 수준에 맞는 강의를 듣고싶었고, 이런 조건에 부합하는 강의로서 조훈님의 강의를 처음 수강했었습니다.(링크)
조훈님 강의는 최대한 쉽게 설명해주시려고 노력하시지만 제가 좋아하는 스타일과는 결이 달라서 1회차 완강을 하고 곧바로 유데미의 강의를 들었습니다.(링크)
유데미 강의는 개념과 적절한 실습을 함께 공부할 수 있어서 도움이 많이 됐었고 해당 강의를 2회차 수강하고 블로그에 관련 내용을 정리하는 식으로 복습했습니다.

2. 실습

유데미 강의에서 제공해주는 KodeKloud의 모든 실습 문제를 2회씩 풀었고 Lightning Labs와 Mock Exams를 각각 5번 넘게 풀어 봤습니다.
CKA 시험 등록 후 Linux Foundation에서 제공해주는 killer.sh의 경우 1회차는 시간내에 제한시간 동안 최대한 풀어보고, 못 푼 문제는 답지를 3번정도 정독 했습니다.
killer.sh 2회차 때도 마찬가지로 제한시간 내에 최대한 풀어보는 연습을 했구요. 다만 2회차에는 1회차 때보다 훨씬 많은 문제를 풀 수 있었습니다.

3. 요약

유데미 강의 2회차 수강(모든 실습 문제 풀이) → 강의 내용 블로그 정리 → Lightning Labs, Mock Exams 각각 5회 이상 풀이 → killer.sh 1회차 풀이 → killer.sh 답지 3회 정독 및 부족한 개념 익숙하게 만들기 → killer.sh 2회차 풀이

3. 팁

시험 환경 : 모든 CKA 시험 후기에서 언급되던 열악한 시험환경(커맨드 반응 속도 느림, 연결 끊김 등)에 대해 걱정을 많이했지만 저는 관련 문제를 경험하지 못했습니다. Linux Foundation이 성능을 개선한 것인지 아니면 제가 시험을 봤었던 시간대가 응시자가 적어서 성능 이슈가 없었던 건지는 모르겠지만요. 다행히 killer.sh에서 문제풀이하는 것과 같은 느낌으로 시험을 치를 수 있었습니다.
시간 배분 : K8s 도큐먼트를 참고해야 풀 수 있을 정도로 익숙하지 않은 문제는 플래그 체크하고 바로 넘어갔습니다. 의도한 것인지는 모르겠지만 쉬운 문제들이 모두 뒷쪽에 있었기 때문에 바로 풀 수 있는 것들부터 풀고 어려운 문제들은 천천히 도큐먼트를 보면서 침착하게 풀어 나갔습니다. 그덕분인지 저는 2시간의 시험 시간이 촉박하지 않았고 오히려 남았었습니다.
문제 정독 : 문제 지문을 꼼꼼히 읽어서 실수를 방지해야 합니다. 가령 특정 노드에만 설정을 적용한다거나, 특정 노드는 배제한다거나 하는 요구사항이 있기 때문에 실수하지 않도록 조심해야 합니다.
SSH exit : 문제 지문에서 컨텍스트를 변경하는 명령어까지 제공해주고 있어 컨텍스트를 혼동할 위험은 없어졌으나, 노드에 ssh로 접근한 경우 다음 문제에서는 반드시 터미널을 exit해야 합니다. 자칫하면 왜 문제에서 말하는 네임스페이스가 없지? 왜 서비스가 없지? 하면서 엉뚱하게 시간 낭비를 할 수 있습니다.

쿠버네티스 Ingress 개념 및 설정

Sun, 13 Nov 2022 14:58:12 GMT

1. 개념

NetworkPolicy의 Ingress와 개념은 같지만 컨셉이 다름
클러스터 외부에서 HTTP/s를 통한 클러스터 내부로의 요청을 처리하는 규칙
예를들어 클러스터에 /member 와 /product 두 개의 애플리케이션을 운영중이고 개별적인 요청을 핸들링하고자 할 때 Ingress 활용

2. 실습

링크 참고

3. Ingress 핸들링

Ingress 리소스 확인 : kubectl get ingress -A
Ingress 리소스 설정 확인 : kubectl describe ingress [인그레스_이름]

참고

쿠버네티스 StorageClass 개념 및 설정

Wed, 09 Nov 2022 15:35:46 GMT

1. 개념

PVC를 이용해 볼륨을 손쉽게 요청할 수 있으나 운영자는 PV로 사용할 볼륨을 수동으로 프로비저닝해 함(Static Provisioning 방식)
이런 불편함을 해결하기 위해 자동으로 볼륨을 생성·할당하는 StorageClass를 사용(Dynamic Provisioning 방식)

2. StorageClass 생성

StorageClass 생성

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: storage.k8s.io/v1
 
kind: StorageClass
 
metadata: 
  name: demo-sc
 
volumeBindingMode: WaitForFirstConsumer 
 
provisioner: kubernetes.io/aws-ebs
 
parameters:
  type: io1
  iopsPerGB: "10"
  fsType: ext4
cs

volumeBindingMode : 볼륨이 언제 바운딩 될지 시기를 설정하는 옵션. 설정하지 않을 경우 Immediate가 기본값으로 설정되나 WaitForFirstConsumer 사용을 권장
- Immediate : PVC가 생성되는 즉시 바인딩. 따라서 의도치않은 PVC가 바인딩 될 가능성 존재
- WaitForFirstConsumer : PVC를 사용할 파드가 생성될때까지 바인딩을 지연
provisioner : PV(볼륨)를 생성할 스토리지 종류. AWSElasticBlockStore, AzureFile 등 다양한 프로비저너가 존재. 링크에서 확인 가능
parameters : provisioner가 동적으로 볼륨을 생성할 때 필요한 옵션

3. PVC에 StorageClass 적용

StorageClass를 요청하는 PVC 생성

1
2
3
4
5
6
7
8
9
10
11
12
13
14
apiVersion: v1
 
kind: PersistentVolumeClaim
 
metadata:
  name: demo-pvc-for-sc
 
spec:
  storageClassName: demo-sc
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi
cs

storageClassName : 사용하고자 하는 SC 설정

4. StorageClass 정보 확인

목록 및 상태 확인 : kubectl get sc
세부정보 확인 : kubectl describe sc [스토리지클래스_이름]

참고

쿠버네티스 PV·PVC 개념 및 설정

Tue, 08 Nov 2022 15:42:42 GMT

1. 개념

영속성을 보장할 수 없는 파드에 데이터를 저장할 경우 언제든 데이터가 사라질 가능성 존재
따라서 파드의 생명주기와 무관하게 저장이 유지되는 데이터 저장소가 필요한데 이런 요구사항을 만족하기 위한 개념이 PV(PersistentVolume)와 PVC(PersistentVolumeClaim)
PV : 데이터를 저장할 볼륨. 볼륨을 생성하고 이를 클러스터에 등록한 것
PVC : 필요한 저장 공간·RW모드 등 요청사항을 기술한 명세로서 PV에 전달하는 요청. PV와 바인딩을 하는 목적으로 사용

2. PV 생성

demo-pv라는 PV 생성

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: v1
 
kind: PersistentVolume
 
metadata:
  name: demo-pv
 
spec:
  capacity:
    storage: 100Mi
  accessModes:
    - ReadWriteMany
  hostPath:
    path: "/pv/log"
  persistentVolumeReclaimPolicy: Retain
cs

capacity : 볼륨 크기
accessModes : 볼륨 RW 모드
- ReadWriteOnce : 하나의 노드에서만 RW 가능
- ReadOnlyMany : 여러 노드에서 R 가능
- ReadWriteMany : 여러 노드에서 RW 가능
persistentVolumeReclaimPolicy : PV 릴리즈(사용 종료) 시 볼륨에 저장된 데이터 삭제 옵션
- Retain : PVC가 삭제되어도 PV(볼륨)의 데이터를 보존. 하지만 해당 PV를 다른 PVC가 사용하지 못하고, 재사용하기 위해서는 수동으로 PV를 반환해야 함
- Delete : PVC가 삭제되면 PV(볼륨)의 데이터를 비롯해 PV(볼륨) 자체를 삭제
- Recycle : PVC가 삭제되면 PV(볼륨)의 데이터만 삭제하고 볼륨 자체는 보존하여 곧바로 다른 PVC에 사용 가능. 하지만 현재는 deprecated되어 사용을 권하지 않음

3. PVC 생성

demo-pvc라는 PVC 생성
1
2
3
4
5
6
7
8
9
10
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: demo-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 50Mi
cs
accessModes : 사용하고자 하는 PV의 accessModes와 동일한 옵션을 사용해야 bound 가능
requests : 사용을 원하는 볼륨의 요구조건을 명시
- storage : 사용하고자 하는 최소한의 크기로서 명시한 용량보다 큰 PV도 상관 없음

4. PV, PVC 정보 확인

목록 및 상태 확인 : kubectl get persistentvolume | persistentvolumeclaims
세부정보 확인 : kubectl describe persistentvolume [PV_이름] | [PVC_이름]

5. 애플리케이션(파드, 디플로이먼트)에서 볼륨 또는 PVC 마운트

볼륨 마운트

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: v1
 
kind: Pod
 
metadata:
  name: webapp
 
spec:
  containers:
  - name: webapp
    image: nginx
    volumeMounts:
    - name: log-vol
      mountPath: "/log"
  volumes:
  - name: log-vol
    hostPath:
      path: "/var/log/webapp"
cs

PVC 마운트

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: v1
 
kind: Pod
 
metadata:
  name: webapp
 
spec:
  containers:
  - name: webapp
    image: nginx
    volumeMounts:
    - name: log-vol
      mountPath: "/log"
  volumes:
  - name: log-vol
    persistentVolumeClaim:
      claimName: demo-pvc
cs

참고

https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/