728x90

Kubenetes 를 사용하면서 namespace 를 통해 큰 단위의 리소스 구분을 해줘야 하는 경우가 종종 생깁니다. namespace 를 감안하여 사용할 수 있는 몇 가지 명령어들 중 udemy 강의 실습에서 나온 커맨드를 정리해 봅니다. 몇 일 쉬고 다시 들으려니 또 까먹은 것들이 많아서 당혹스럽네요 ㅜㅜ 듣고 있는 CKA Udemy 강의는 아래 링크입니다. 

 

 

 

Certified Kubernetes Administrator (CKA) Practice Exam Tests

Prepare for the Certified Kubernetes Administrators Certification with live practice tests right in your browser - CKA

www.udemy.com

 


redis 이미지를 사용하는 간단한 pod 생성 코드

apiVersion: v1
kind: Pod

metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: redis

 

Pod 를 특정 Namespace 에 생성하기

kubectl create -f pod.yaml --namespace=finance

 

모든 Namespace 의 Pod 목록 확인하기

kubectl get pods --all-namespaces

 

특정 Namespace 의 Pod 목록 확인하기

kubectl get pods --namespace=research

 

redis 이미지를 사용하는 간단한 pod 생성 코드 + namespace 지정

apiVersion: v1
kind: Pod

metadata:
  name: redis
  nemaspace: finance <-- 추가된 부분
spec:
  containers:
  - name: redis
    image: redis

 

기본 namespace(default) 를 특정 namespace 로 고정하기

// 현재의 context 를 가져온 뒤 research namespace 를 기본 값으로 변경
kubectl config set-context $(kubectl config current-context) --namespace=research

 

namespace 의 생성

// yaml 을 이용하는 방법
// namespace.yml
apiVersion: v1
kind: Namespace
metadata:
  name: new-namespace

// 생성한 파일을 이용하여 namespace 생성 
$ kubectl create namespace -f namepsace.yml
// 커맨드라인 명령으로 namespace 생성
kubectl create namespace new-namespace

 


 

본 포스팅은 제휴마케팅 링크를 포함하고 있으며 소정의 수수료를 지급받을 수 있습니다. 

 

 

728x90
728x90

CKA (Certified Kubenetes Administrator) 시험을 꽤 실무적인 시험으로 알려져 있습니다. 단답형 지식을 묻는 질문이 주류를 이루고 있어 스펙을 많이 기억해야 하는 다른 시험과 달리 실제 터미널 환경에서 쿠버네티스에 대한 컨트롤을 얼마나 잘 하고 이해하고 있는지를 확인하는 시험입니다. 네, 아직 취득한건 아닙니다 ㅎㅎ 

원격으로 감독관이 컴퓨터 환경을 감시(?)하며 시험이 진행된다고 알려져 있어서 따로 정리한 레퍼런스를 활용하는 것이 어렵다고 합니다. 따라서 유용한 커맨드들을 기억해 두고 시험에 임하면 좋다고 하네요. 듣고 있는 강의에서 정리해준 몇 가지 커맨드를 잊지 않기 위해 정리해 봅니다. 

 

Certified Kubernetes Administrator (CKA) Practice Exam Tests

Prepare for the Certified Kubernetes Administrators Certification with live practice tests right in your browser - CKA

www.udemy.com


 

NGINX Image 를 이용하여 NGINX Pod 생성하기

kubectl run nginx --image=nginx

 

Deployment 생성하기

kubectl create deployment --image=nginx nginx

 

Deployment 구성을 위한 Yaml 템플릿 생성하기 (단, 배포 없이)

kubectl create deployment --image=nginx nginx --dry-run=client -o yaml

 

Deployment 구성을 위한 Yaml 템플릿을 4개 ReplicaSets 를 갖는 구성으로 생성 (단, 배포 없이)

kubectl create deployment --image=nginx nginx --dry-run=client --replicas=4 -o yaml > nginx-deployment.yaml

 

예제 시험문제를 몇 가지 풀다보니 손으로 Yaml 파일을 구성해야 하는 시나리오가 종종 나오는 것 같습니다. 시행착오를 줄이고 시간을 단축하기 위해, 위의 명령들로 템플릿을 생성해서 변경하는 방식이 아무래도 시험 볼 때 마음을 편안하게 해주겠죠? 기초적인 명령들이지만 익숙하지 않다보니... 일단 여기까지!


 

본 포스팅은 제휴마케팅 링크를 포함하고 있으며 소정의 수수료를 지급받을 수 있습니다. 

728x90
728x90

Cloud Platform 을 사용할 때 가장 조심해야 하는 것 중 하나가, 각 플랫폼이 가지고 있는 QoS (Quality of Service) 수치를 넘지 않도록 해야 한다는 것입니다. 물론, 이 수치는 Support Ticket 등을 통해 늘리는 것이 가능하지만 시간이 소요될 수 있기 때문에 이벤트 등 대규모 사용자가 몰리는 이벤트가 준비중이라면 미리 체크를 해두어야 합니다. 

CDN 제품인 AWS CloudFront 도 마찬가지인데요, 적용되고 있는 여러가지 제한 중 이벤트 트레픽에 대한 고려사항은 크게 1) 대역폭에 대한 Limit 과 2) 요청수에 대한 Limit 이 있습니다. AWS 공식 문서에서는 `할당량` 또는 `Quotas` 로 제품 문서에서 확인할 수 있는 내용입니다. 


대역폭과 전송량 제한

CloudFront 의 할당량 정책은 기본적으로 Distribution 당으로 적용됩니다. 참고로 시장 지배 사업자인 아카마이 Akamai 의 경우 Bucket 이라는 컨셉이 있고 CP Code 단위로 대역폭에 대한 관리만 하고 있습니다. 아카마이와 달리 CloudFront 의 경우 대역폭과 요청량의 두가지 제한이 있습니다. 

출처 : CloudFront 개발자 안내서

Distribution 을 `배포` 라고 표현하고 있는 부분은 늘 적응이 잘 안되네요. API 에서도 distid 등을 사용하니 Distribution 으로 인지하는 것이 편합니다. 공식 문서에 나온 것처럼 대역폭은 150Gbps 가 기본 제한이고 요청량은 250,000rps 가 기본 제한으로 들어가 있습니다. 바로 아래에 있는 `더 높은 할당량 요청`이 있는 이유는 조정이 가능하기 때문이겠죠? ^^

`더 높은 할당량 요청`을 누르면 Support 페이지로 넘어가고 `Service Limit Increase` 타입의 티켓을 열어 할당량을 높이는 방식입니다. 느낌이 오시겠지만 시간이 좀 걸릴 수 있는 부분이라 예측하지 못한 트레픽 Burst 가 아니고 계획된 이벤트라면 미리 할당량을 조정해 두시는 것이 정석입니다. 

 

할당량 초과는 어떻게 알 수 있을까?

CloudFront 에서는 위의 할당량이 초과 되었다 하더라도 알려주는 것은 없습니다. 요행히 CloudWatch 로 Distribution 의 에러 비율에 대한 알람을 걸어두었다면 메일을 통하여 한템포 늦게 인지할 수 있는 방법이 있긴 합니다. 다른 방법으로는 CloudFront 의 Monitoring 화면에서 사용자의 트레픽이 급격히 늘면서 5xx 에러가 증가했는지를 확인하는 방법이 있습니다.

후행적으로 확인하는 방법은 (이미 장애는 났고... 사용자는 영향을 받았고...) CloudFront 의 Access Log 를 통하는 방법이 있습니다. Access Log 의 필드중 2020년 12월 3일 기준으로 14번째 컬럼인 `x-edge-result-type` 이나 23번째 컬럼인 `x-edge-response-result-type` 의 값을 이용해서 확인할 수 있습니다. 

14번째 컬럼의 값
23번째 컬럼의 값

이 필드의 값으로 `LimitExceeded` 가 특히 할당량, Limit 초과에 대한 부분입니다. 문제는 LimitExceeded 가 어떤 Limit 을 초과한 것인지를 알려주지 않습니다. 알고 싶다면 <또> Support Ticket 을 열어야 합니다. 해보신 분들은 아시겠지만 Ticket 을 열면서 꼭 샘플 로그를 추출해서 제공해 주셔야 합니다. 


용량관리는 인프라에서 무척 중요한 부분입니다. 우리가 클라우드 서비스를 이용하는 이유중 하나는 그런 용량 관리로부터 조금이나마 자유롭고 싶어서 이지만, 결국 클라우드 서비스도 그들 입장에서는 용량관리를 해야만 합니다. 때문에 위와 같은 제한들이 존재하고 사용하고 있는 사업자의 숫자들을 기억해 둘 필요가 있습니다. 

> 참고 URL

 

할당량 - Amazon CloudFront

할당량 CloudFront에는 다음 할당량(이전에는 제한으로 지칭)이 적용됩니다. Lambda@Edge에는 기본 CloudFront 할당량에 추가하여 적용되는 특정한 할당량도 있습니다. 일반 할당량 엔터티 기본 할당량

docs.aws.amazon.com

 

표준 로그(액세스 로그) 구성 및 사용 - Amazon CloudFront

모든 이벤트에 대한 값이 있는 필드도 있고 재생, 중지, 일시 중지, 일시 중지 취소 및 탐색 이벤트에 대한 값만 있는 필드도 있습니다. 일반적으로 로그 파일에서 필드에 대해 하이픈(-)이 포함

docs.aws.amazon.com

 

728x90
728x90

VPN 과 관련한 여러가지 시험, 환경을 구축하다보니 로컬 라우팅 테이블이 꼬이는 현상이 발생하여 조사를 해보았습니다. 평소 사용하고 있던 IPv4 VPN 와 IPv6 VPN, 그리고 개별 과제로 만들고 있는 OpenVPN 기반의 IPv6 까지 아주 난장판이라 이런 문제가 생긴다고 생각해서 트러블슈팅 방법을 좀 정리해 보고자 합니다. (미래의 내가, 과거의 나를 찾을 것이 분명하니...)


지저분해지는 IPv6 라우팅 테이블

안그래도 복잡했던 로컬 IPv6 라우팅 테이블이 심하게 꼬인 것은 로컬 환경에서 OpenVPN Web UI 디버깅을 위해 OpenVPN 을 설치하고 구동하면서 부터였습니다. 오늘 아침 개발조직에 IPv6 접근 가이드를 해주기 위해 WIKI 를 정리하다보니 평소 사용하던 IPv6 VPN 에 연결하더라도 v6 웹 사이트 (가령 v6.google.com) 에 접근이 안되는 것을 확인했습니다. 

미처 캡쳐를 해두진 못했지만 netstat -nr 로 로컬의 라우팅 테이블을 살펴보니 스태틱으로 잡힌 테이블이 너무 많았습니다. VPN 연결시 생성되는 인터페이스인 utun 시리즈도 무려 6개나 존재하더군요. 인터페이스를 down 으로 하는 것과 라우팅 테이블은 별개라 한땀 한땀 삭제를 해주어야 했습니다. 사용한 명령들은 대략 아래의 패턴입니다. 

// 한 땀, 한 땀 삭제...
sudo route delete -inet6 ##v6주소##%utun0

// default 를 잠식한 utun 시리즈 삭제는 -ifscope 으로...
sudo route delete -inet6 default -ifscope utun1

이렇게 삭제를 하고나니 라우팅 테이블이 깔끔해졌습니다. 이제 라우팅 테이블을 지저분하게 만든 범인을 찾기 위해 간단한 스크립트로 리눅스 환경에서의 watch 를 구현하여 netstat -nr 명령을 반복하도록 해보았습니다. 우리가 기대하는 것은 VPN 연결시 필요한 라우팅 테이블이 추가 되었다가 VPN 연결을 종료하면 라우팅 테이블이 정리되는 것이겠죠!?

// Mac 환경에서 리눅스 watch 스타일로 명령 구동하기
while true; do clear; netstat -nr; sleep 2; done;

 

회사가 제공한 VPN 시험

먼저 회사가 제공한 IPv6 VPN 을 살펴보았습니다. 심증은 <범인은 OpenVPN 이다!> 였지만 확실하게 하기 위해서죠. 개발팀도 분명 비슷한 증상을 겪을 수 있으니 FAQ 를 준비하는 목적도 있었습니다. 자, 우선 IPv6 VPN 연결전에는 아래와 같이 깔끔한 라우팅 테이블 목록을 볼 수 있습니다. 물론... 앞서 이야기 한 것처럼 한 땀, 한 땀 라우팅 테이블을 정리한 상태입니다 ㅜㅜ

회사에서 셋업한 IPv6 VPN 을 연결해 보니 utun 인터페이스로 다수의 라우팅 테이블이 추가되는 것을 확인할 수 있었습니다. 

다시 VPN 연결을 끊었을때 v4, v6 쪽으로 추가된 라우팅 테이블이 깔끔하게 정리되는 것을 확인할 수 있었습니다. 범인은 OpenVPN 일까요? 확인해 보았습니다.

 

AWS 에 구축한 IPv6 OpenVPN 시험

이번에는 AWS 에 구축해 둔 IPv6 OpenVPN 을 시험해 보았습니다. VPN 에 연결되면 이전의 다른 VPN 과 마찬가지로 다량의 라우팅 테이블이 추가되는 것을 확인할 수 있었습니다. 이번에도 동일하게 utun4 를 사용했군요. 터널 인터페이스가 만들어지고 삭제되는 과정도 좀 궁금하지만 따로 알아보기로 하고...

자 이제... 대망의 연결 종료의 시간이 되었습니다. OpenVPN 연결을 종료했을때 깔끔하게 라우팅 테이블이 정리되었으면 하는 바램을 갖고... 도전!

이런... 예상과 다르게 너무 깔끔하게 라우팅 테이블이 정리가 되었습니다. 문제가 생기길 기대(?)했는데 깔끔해진 걸 보니... 뭔가 OpenVPN 에 등록해 둔 Profile 들을 시험하는 과정에, 연결이 깔끔하지 못했거나 강제 종료된 경우 등 예외 상황에서 문제의 현상이 나오는 것일 가능성이 생겼습니다. 

AWS EC2 를 이용한 OpenVPN 구축 연재는 아래 글타래로... (2편은 아직 못쓴...)

 

AWS EC2 를 이용한 IPv6 지원 OpenVPN 구축 #1

코로나 바이러스의 두번째 웨이브가 한창입니다. 다행히 오늘(9/3) 기준으로 확진자 수가 200명 밑으로 내려오긴 했지만, 긴장의 끈을 놓기에는 여전히 확진자 수가 많습니다. 많은 기업들이 원격

ondemand.tistory.com

 

Mac 로컬 환경의 OpenVPN 시험

내친김에 로컬 환경의 시험도 해보았습니다. 조금 까리한 것은 로컬에서는 초기에 proto udp 로 시험하다보니 AF_INET6 로 서버가 구동되는 문제가 있어서 proto udp4 로 설정해둔 상태였습니다. 만약, 이 상태에서도 문제가 없다면 proto udp 일때 AF_INET6 로 구동되는 과정, 종료되는 과정의 문제라고 생각해도 될 것 같았습니다. 

참고로 utun4 는 로컬의 OpenVPN 서버가 점유하고 있는 터널이고, utun7 은 로컬의 Tunnelblick 이 연결을 맺으면서 생성한 인터페이스입니다. 자, 이제 연결을 끊어보겠습니다. 

오오... 찾은 것 같습니다. Tunnelblick 종료시 utun7 이 빠졌고, OpenVPN 서버 종료시 utun4 가 빠졌지만, Internet6 쪽에 추가된 스태틱 라우팅 하나가 빠지지 않은 것을 확인할 수 있었습니다. 설정의 문제인지는 조금 더 조사해 봐야하고 로컬 환경에서만 생기는 문제인지 명확하진 않습니다만, 최소한 FAQ 에 기술해두고 개발자 분들께 가이드 하는데는 문제 없을것 같습니다. 


뭔가 완전히 잘 알지 못하는 분야는 늘 시행착오가 생기는 것 같습니다. 오늘도 몇 가지 시행착오를 겪으면서 한 걸음, 한 걸음, 뚜벅 뚜벅 걸어나가 봅니다!

 

728x90

+ Recent posts