Study_note
[kubernetes] PKOS(쿠버네티스)3주차 - Ingress & Storage 본문
과제 1. Ingress(with 도메인, 단일 ALB 사용)에 PATH /mario 는 mario 게임 접속하게 설정하고, /tetris 는 tetris 게임에 접속하게 설정하고, SSL 적용 후 관련 스샷
tetris, mairo 이미지 기반에 디플로이먼트 및 서비스, ingress 생성
apiVersion: apps/v1
kind: Deployment
metadata:
name: tetris
namespace: games
labels:
app: tetris
spec:
replicas: 1
selector:
matchLabels:
app: tetris
template:
metadata:
labels:
app: tetris
spec:
containers:
- name: tetris
image: bsord/tetris
---
apiVersion: v1
kind: Service
metadata:
name: tetris
namespace: games
annotations:
alb.ingress.kubernetes.io/healthcheck-path: /tetris/index.html
spec:
selector:
app: tetris
ports:
- port: 80
protocol: TCP
targetPort: 80
type: NodePort
apiVersion: apps/v1
kind: Deployment
metadata:
name: mario
namespace: games
labels:
app: mario
spec:
replicas: 1
selector:
matchLabels:
app: mario
template:
metadata:
labels:
app: mario
spec:
containers:
- name: mario
image: pengbai/docker-supermario
---
apiVersion: v1
kind: Service
metadata:
name: mario
namespace: games
annotations:
alb.ingress.kubernetes.io/healthcheck-path: /mario/index.html
spec:
selector:
app: mario
ports:
- port: 80
protocol: TCP
targetPort: 8080
type: NodePort
externalTrafficPolicy: Local
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: games
name: games-ingress
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/certificate-arn: acm arn
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
alb.ingress.kubernetes.io/healthcheck-port: traffic-port
alb.ingress.kubernetes.io/healthcheck-interval-seconds: '15'
alb.ingress.kubernetes.io/healthcheck-timeout-seconds: '5'
alb.ingress.kubernetes.io/success-codes: '200'
alb.ingress.kubernetes.io/healthy-threshold-count: '2'
alb.ingress.kubernetes.io/unhealthy-threshold-count: '2'
spec:
ingressClassName: alb
rules:
- host: web.satest.click
http:
paths:
- path: /tetris
pathType: Prefix
backend:
네임스페이스가 games 기반에 deployment, ep, svc, ingress 생성 확인
여기서 mairo, tetris 파드 및 다른 서비스, 엔드포인트 전부 작동되는데
tetris로 트래픽을 보낼때 계속 404 에러가 발생하였고 트러블슈팅할려 했지만 결국 원인을 찾지 못했다.
과제 2. 호스트 Path(local-path-provisioner) 실습 및 문제점 확인과 성능 측정 후 관련 스샷
hostpath를 사용하면 파드가 생성된 노드의 볼륨을 사용하므로 다른 노드에서 해당 파일에 접근할 방법이 없다.
다르게 생각한다면 만약 해당 노드가 죽으면 다른 노드에서는 hostpath를 사용할 수 없기 때문에 데이터는 모두 죽는다.
Hostpath 없이 일반적인 Deployment를 구성하였을 때는 특정 노드를 drain해서 모든 파드를 종료한다고 하더라도 다른 노드에서 바로 필요 수량만큼 파드가 되살아난다.
만약 특정 노드에 hostpath 볼륨을 사용하는 경우, 해당 노드가 죽어도 deployment는 다른 노드에 파드를 다시 실행하지 못한다.
아래와 같이 hostpath 스토리지클래스를 사용하는 파드는 drain 또는 스케줄링 등 다른 노드로 가게된다면 통신이 불가하다.
4k 디스크 블록 기준 Write, Read 평균 IOPS은 아래와 같다
과제 3. AWS EBS를 PVC로 사용 후 온라인 볼륨 증가 후 관련 스샷
csi가 설치되어있는것을 확인 (gp3 기반에 1-21 버전이 default)
pvc와 생성한 pvc를 마운트할 pod 생성
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: ebs-claim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 4Gi
---
apiVersion: v1
kind: Pod
metadata:
name: app
spec:
terminationGracePeriodSeconds: 3
containers:
- name: app
image: centos
command: ["/bin/sh"]
args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: ebs-claim
생성한 pvc를 4gi에서 10gi로 수정하면 아래와 같다.
과제 4 AWS Volume SnapShots 실습 후 관련 스샷
볼륨 스냅샷을 하기 위해 crd 생성 후 볼륨 스냅샷 클래스 생성
생성했던 ebs를 source로 ebs 스냅샷 생성
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: ebs-volume-snapshot
spec:
volumeSnapshotClassName: csi-aws-vsc
source:
persistentVolumeClaimName: ebs-claim
아래와 같이 생성했던 스냅샷을 datasource로 선정하여 pvc로 복원도 가능하다.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: ebs-snapshot-restored-claim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 4Gi
dataSource:
name: ebs-volume-snapshot
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io