나왔던 문제 복기

1. ingress

ingress 문제정의

pong 이라는 이름을 가진 ingress 만들어라
namespace 는 ing-internal
/hi 로 요청이 들어오면 hi 서비스 5678 포트로 라우팅 해
curl -kL {Internal-ip}/hi 로 테스트 할수있다

ingress 설명

쿠버네티스에서 인그레스는 L7 수준에서 리버스 프록시 역할을 한다.

쉽게 말해서 엔드유저가 클러스터 내의 어플리케이션에 접근을 할때 ingress 를 거치게 되고, 이 때 ingress의 rule 에 의해서 라우팅 된다.

예로들어 엔드유저가 아래 두개의 사이트를 방문한다고 가정해보면

• http://xxx.com/shop
• http://xxx.com/blog

path 에 따라 어플리케이션을 특정해야 할 때 ingress 가 사용된다.
(정확히는 서비스에 대한 라우팅 규칙을 정의)

• /shop -> shop 어플리케이션
• /blog -> blog 어플리케이션

덕분에 ALB(어플리케이션 수준에서 로드밸런싱)를 수월하게 할 수 있다.

풀이법

## -h 명령어를 통해서 템플릿 파악
kubectl create ing -h | grep -A 1 Usage
>> 
Usage: 
  kubectl create ingress NAME --rule=host/path=service:port[,tls[=secret]]  [options] 

## Usage 적용해서 pong ingress 생성하기 네임스페이스 반드시 넣기
kubectl create ing pong --rule=/hi*=hi:5678 -n ing-ingernal --dry-run=client -o yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  creationTimestamp: null
  name: pong
  namespace: ing-ingernal
spec:
  rules:
  - http:
      paths:
      - backend:
          service:
            name: hi
            port:
              number: 5678
        path: /hi
        pathType: Prefix
status:
  loadBalancer: {}

위 yaml 을 apply 하면 문제는 풀린다.

ingress flow
엔드포인트 요청 -> 워커 노드 -> 인그레스 컨트롤러 서비스 -> 인그레스 -> 서비스 -> 파드

지문에 있는 {Internal-IP}가 무엇의 내부 ip 를 의미 하는건지 생각이 나지 않아서
ingress는 외부에서 노드 접근했을때의 rule 이니까 테스트 파드 한개 생성하고
그 파드 내부에서 curl -kL http://node-external-ip/hi 로 테스트 했다.
response 나오길래 설정됐다 판단하고 넘어갔다.

지금 생각해보면 내부 요청이면 워커 노드 내부 ip 혹은 인그레스 컨트롤러 서비스 cluster-ip 를 통해서 접근 해보라는 거같은데 노드 내부 ip 는 ingress 취지에 어긋나는거 같아서 정확하게 테스트 하려면 인그레스 컨트롤러 서비스 cluster-ip 를 internal-ip 에 대입하는게 맞을거 같다.

결론적으로 아래방법으로 테스트

## 아래 명령어로 node internal-ip 를 받을 수 있음
kubectl get nodes -o wide 

## 테스트 파드 생성하면서 curl 명령어 날리기
kubectl run test-ing -n ing-internal 

##
curl -kL <Ingress 컨트롤러 서비스 클러스터 ip>/hi

2. pv,pvc

문제정의

1. pv 만들어라
2. pvc 만들어서 위 pv bound 시켜라
3. 파드 만들어서 pvc 볼륨 마운트 시켜라
4. patch 나 edit 명령어 사용해서 expand volume 하세요 record 도 해라

pv, pvc, add to pod 는 너무 잘 나오는 내용이라 패스 patch나 edit 으로 volume 확장하는건 안해봤고, record 도 생소해서 우선은 Kubernetes.io 에 patch pv를 찾아봤다.

예제는 reclaim policy 변경하는것만 나와있어서
kubectl desribe pv 해서 storage jsonpath 찾아서 -p 아랫부분만 변경했다. 그리고 record 부분은 deployment rollout record 할때처럼 --record 옵션사용

풀이법

kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

###위 템플릿 이용해서 storage 변경
kubectl patch pv <your-pv-name> -p '{"spec":{"capacity":{"storage":"70Mi"}}}'

###record 추가
kubectl patch pv <your-pv-name> -p '{"spec":{"capacity":{"storage":"70Mi"}}} --record'

3. etcd backup && restore

etcd 백업 이건 정말 무조건 나오는 기출인데 틀렸다.
마스터 노드들어가서 sudo 권한으로
etcdctl snapshot save 하고
etcdctl --data-dir 로 snapshot 이전에 있던거 복구했는데 etcd pod 상태가 계속 pending 이였음.

문제정의

https://127.0.0.1:2379 에서 실행중인 etcd 인스턴스 스냅샷 찍어서
/var/~ 에 저장해라
tls 어쩌구 ca/key 사용해라(경로 제공)
그리고 이전에 찍어놨던 previous-snapshot 으로 etcd 복구해봐라

기본개념

etcd 는 쿠버네티스 DB 로 마스터 노드에 위치한다. key:value 형식으로 데이터를 저장하는데 이 데이터를 snapshot 찍어서 백업하고 복구할 수 있다.

저장소 위치는 마스터 노드 volume 을 마운트 시켜서 사용 하는데 /etc/kubernetes/manifests/etcd.yaml 을 보면 알 수 있다.
(보통 /var/lib/etcd) 따라서 restore 할 때 snapshot 데이터를 풀어주는 위치와 mount 하는 volume 의 hostPath 를 동기화 시켜주는 작업이 필요하다.

풀이법

1. ssh k8s-master(마스터 노드 들어가기)
2. sudo -i(root 사용자 권한 필요)
3. 백업 (cacert, cert, key 는 문제에서 주어짐)

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> \
  snapshot save <backup-file-location>

-> Snapshot saved at <backup-file-location>

4. restore

## <data-dir-location>: snapshot.db 데이터를 풀어줄 저장소 위치
ETCDCTL_API=3 etcdctl --data-dir <data-dir-location> snapshot restore snapshot.db

이후에 etcd.yaml 파일에 volume 경로를 해당 위치로 수정이 필요하다.
etcd.yaml 위치 -> 마스터 노드 /etc/kubernetes/manifests/etcd.yaml
static 파드이기 때문에 yaml 수정하면 자동으로 반영된다.

시험 결과