갬미의 성장일기
Day 49 - k8s 인그레스 구글 인증서 사용하기, k8s LB 알고리즘, k8s deployment 본문
오늘 배운 내용
- 쿠버네티스 인그레스 TLS 구글 인증서 사용하기
- 로드밸런싱 알고리즘
- 쿠버네티스 deployment
쿠버네티스 인그레스 TLS 구글 인증서 사용하기
인증서 종류로는 사설인증서와 공인인증서가 있는데 사설인증서를 사용하는 서버는 브라우저가 안전하지 않은 사이트로 인식하여 접속이 한번 막히게 된다
공인인증서는 신뢰할 수 있는 기관에서 발급 받을수 있으며, gke에서는 서버에서 사용할 수 있는 인증서를 발급받일 수 있다
해당인증서는 gke의 LB에서만 사용 가능하다
다음 yml파일을 만들고 실행한다
# managed-cert.yml
apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
name: managed-cert
spec:
domains:
- v1.mymincloud.com
ingress.yml을 다음과 같이 설정한다
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myingress
annotations:
kubernetes.io/ingress.global-static-ip-name: "k8s-ip" # gcp의 static ip
networking.gke.io/managed-certificates: managed-cert # gcp certification
networking.gke.io/v1beta1.FrontendConfig: "https-redirect"
spec:
rules:
- host: v1.mymincloud.com
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: mynginx # 적용할 svc 이름
port:
number: 80
인증서를 tls-crt가 아닌 구글에서 만든 인증서를 사용하기 때문에 annotation에 managed-cert를 추가하고 기본의 tls부분을 삭제한다
GCP 콘솔에서도 인증서를 확인할 수 있다
인증서가 active되면 다음과같이 신뢰할 수 있는 사이트라고 접속이 된다
요즘은 https 통신이 대부분이며 보안을 생각해야하는 경우 꼭 tls 통신을 해야한다
로드밸런싱 알고리즘
k8s로 3tier를 구성할때, rs로 pod를 만드는 경우 was 서버가 여러개라면 whitelabel error가 발생할 수 있다
왜 그럴까?
Asymmetric error라고 하며 이는 로드밸런싱 알고리즘에 의해 일어난다
was서버가 여러대인경우 svc는 각 pod에 라운드로빈 분배방식을 사용하여 부하를 분산한다
사용자의 정보가 첫번재 파드로 전달 되어 첫번째 pod에 세션정보가 있다
-> 다음에 접속할때 두번째 pod로 전달된다면 로그인 세션이 없어 에러발생
만약 특정 클라이언트가 특정 Pod로 지속적으로 연결이 되게 하려면 Session Affinity를 사용하면 되는데, 서비스의 spec 부분에 sessionAffinity: ClientIP로 주면 된다. (was의 Session Affinity를 수정)
사용자가 최초 접속한 로그가 적용되어 적용된 쪽으로만 보내지는것!
was-svc를 수정한다
kubectl edit svc mywas
sessionAffinity Rule을 Node 에서 ClientIP로 변경한다
미니과제
지금 상황에서 ingress 적용하기
지금 상황 :
web svc (LB) -- web pod -- was svc -- was pod -- DB svc -- DB pod
실행 순서
1. nginx svc type를 LB에서 nodeport로 바꾼다
2. 인증서를 만들고 해당 인증서로 secret을 생성한다
kubectl create secret tls tls-crt --key tls.key --cert tls.crt
3. https redirection
https redirection을 위한 frontend yaml을 하나 만든다
4. frontend yml을 먼저 실행하고, ingress yml을 실행한다
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myingress
annotations:
kubernetes.io/ingress.global-static-ip-name: "k8s-ip" # gcp의 static ip
networking.gke.io/v1beta1.FrontendConfig: "https-redirect"
spec:
tls:
- hosts:
- v1.mymincloud.com
secretName: tls-crt
rules:
- host: v1.mymincloud.com
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: mynginx # 적용할 svc 이름
port:
number: 80
Deployment
Deployment는 서비스의 배포를 쉽게할 수 있도록하는 k8s의 기능으로 recreate 업데이트와 rolling update는 deployment로 자동화가 가능하다
deployment가 등장하기 이전에는 컨테이너에 들어가는 애플리케이션의 소스가 변경된경우 다시 레플리케이션 컨트롤러를 새로 만들고 rolling-update 수행했다.
deployment를 사용하면 pod의 컨테이너의 이미지만 변경해주면 알아서 업데이트가 되며 히스토리 확인 및 롤백기능까지 사용할 수 있다.
pod ⊂ rs ⊂ deployment
deployment로 서비스 제공해보자
deploy.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deploy
spec:
replicas: 10
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: gymin97/msa2:nginx_v1
ports:
- containerPort: 80
svc.yml
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
spec:
selector:
app: nginx
ports:
- port: 80
targetPort: 80
type: LoadBalancer
deployment의 이미지를 바꾸고 다시 적용하면
pod가 알아서 바뀐다
수동으로 롤링업데이트 하는 것과 같은 결과를 보임
일일 과제
- 카나리 업데이트를 간단하게 구현해보기 (beta test)
- ingress를 이용해서 uri 라우팅을 통해 구현하기
- ingress yml 생성 구성은 잘 되었는데 nginx로 ingress uri 라우팅을 하는경우 404 에러 관련 이슈가 있어 내일 다시 진행하기로 했다 제법 흔한 에러인지 로그가 많은데 시도해봐도 안되는게 많다. 뭔가 내일 새로운 마음으로 다시 해보면 될것같긴하다
오늘의 회고
- 구글로 인증서를 받을수 있는지 몰랐는데 생각보다 서비스가 엄청 많은것같다
- 편리함을 위해 이것저것 엮여있는 기능이 많아서 갑자기 헷갈릴때가 많은데 배울때마다 잘 정리해서 넘어가야겠다
- 하루하루 작은 과제를 주시는데 잘 정리해두면 좋을 것 같다! 틈날때마다 조금씩 해야겠다
'Cloud > Cloud 공부일기' 카테고리의 다른 글
Day 51 - k8s Volume, job, cron job, configmap (0) | 2022.03.23 |
---|---|
Day 50 - k8s DaemonSet, k8s Volume (0) | 2022.03.22 |
Day 48 - 쿠버네티스 인그레스 TLS , 쿠버네티스 3tier 구성하기 (0) | 2022.03.18 |
Day 47 - 쿠버네티스 인그레스 (0) | 2022.03.17 |
Day 46 - 쿠버네티스 서비스, 로드밸런서 (0) | 2022.03.16 |