Life On Cloud

PKOS 스터디 소개 올해도 영광스럽게 가시다님의 쿠버네티스 스터디에 참여하게 되었다. 이번에 PKOS(Production Kubernetes Online Study)스터디는 현업에서 쿠버네티스를 사용하는 현직자를 위한 스터디다. 가시다님의 스터디가 워낙 유명하고 인기가 많다보니(가치로 따지면 100만원 이상 돈 내고 들어야 하는 스터디다..) 이번 스터디 모집에도 사람이 엄청 몰렸다. 그래서 두팀으로 나눠서, 1월에는 가시다님 스터디에 처음 참여하는 분들, 그리고 3월에는 가시다님 스터디 기존 참여자고인물분들이 참여하게 되었다. 스터디 소개: (’23) 쿠버네티스 실무 실습 스터디 (기존멤버 대상) 이번 PKOS 스터디는 스터디, 스터디 노션 자료, 과제(본 포스팅) 모두 책 내용을 기반으로 진행한다...

분야 별로 공식 URL을 정리했습니다다. ◼︎공식 홈페이지 https://cloud.google.com/ 문서 https://cloud.google.com/docs/ 아이콘 https://cloud.google.com/icons *언어 설정을 영어로 하고 봐야 최신 아이콘이 업데이트 되어있습니다. 아키텍처 그리기 툴 https://googlecloudcheatsheet.withgoogle.com/architecture Status board https://status.cloud.google.com/ Google Cloud 위치 https://cloud.google.com/about/locations Compute Engine 리전 https://cloud.google.com/compute/docs/reg..

1. Network Policy 요약 2. Network Policy 의 manifest파일 이해하기 2-1. 그림으로 한 눈에 보는 Network Policy 2-2. to 및 from 셀럭터의 동작 2-2-1. and 2-2-2. or 2-3. 포트 범위 지정 2-4. Network Policy 기본 정책 2-4-1. (기본값)모든 Ingress와 모든 Egress 트래픽 허용 2-4-2. 모든 Ingress와 모든 Egress 트래픽 거부 2-4-3. 모든 Ingress 트래픽 거부 2-4-4. 모든 Egress 트래픽 거부 2-4-5. 모든 Ingress 트래픽 허용 2-4-6. 모든 Egress 트래픽 허용 3. 참고 링크 1. Network Policy 요약 쿠버네티스의 네트워크를 레이블, I..

안녕하세요. 네이버클라우드 콘텐츠 마스터 라온클 이수진입니다. 지난 2월 15일 네이버클라우드 강남 교육장 Ncloud Space에서 열린 에 다녀왔습니다. 퇴근길 밋업 소개 퇴근길 테크밋업은 평일 저녁에 열리는 테크 모임입니다. 작년 초엔 온라인으로 열리다가, 이젠 오프라인 행사로도 열리고 있습니다. 이번 2월에 열린 테크 밋업의 주제는 챗봇💬이었는데요. 챗봇 밋업에는 현직 챗봇 기획자, 챗봇 개발자 그리고 챗봇을 더 잘 이해하고 싶은 분들이 모여서 야기를 나누었습니다 :) 이미지 출처: https://blog.naver.com/n_cloudplatform/223026580975 자기소개 발표 전에 밋업에 참석하신 참관자, 사회자, 발표자 분들 모두 사전에 제출한 [MBTI를 곁들인 자기소개] 시간이 ..

(특정 네임스페이스 안에서)시스템 자원에 대한 사용량을 오브젝트 단위로 관리하는 방법 시스템 자원에 대한 사용량을 오브젝트 단위로 관리하는 방법 별도의 오브젝트마다 정의해줄 수 있다.(pod에 대해, pvc에 대해) Limit Ranges는 네임스페이스 단위로 관리한다 오브젝트 단위로 사용량을 관리하되, 그 범위는 클러스터 전체가 아닌 특정 네임 스페이스 안에서만 적용된다. 1네임스페이스 1Limit Ranges A네임스페이스에 Limit Ranges가 생기면, 오직 해당 A네임스페이스에만 Limit Ranges가 적용된다. Limit Ranges의 type으로는 Container, Pod, PersistentVolumeClaim 세가지가 있다. Limit Ranges를 넘는 사양의 Pod를 생성하면 생..

Ingress는 HTTP, HTTPS 등 네트워크 Layer 7에 대한 설정을 담당하는 리소스다. Ingress의 가장 기본적인 역할은 외부 HTTP 호출에 대한 트래픽을 처리하는 것이다. (예시 : 부하 분산, TLS 종료, 도메인 기반 라우팅 기능 등) Ingress는 쿠버네티스 클러스터 내부 서비스에 외부에서 접근 가능한 URL을 부여함으로써 일반 사용자들이 쉽게 접근할 수 있는 통로를 제공한다. Ingress에는 그에 맞는 Controller가 존재하며, Ingress Controller는 Ingress에 정의된 트래픽 라우팅 규칙을 보고 라우팅을 수행한다. Ingress 리소스 자체로는 어떠한 프로그램이 작동하는 코드가 아니라 트래픽 처리에 대한 정보를 담고 있는 정의에 가깝다. 예를 들어, 일..

롤링 업데이트 새 버전을 배포하면서, 기존 Pod를 제거하고, 새로운 버전의 pod를 지정한 개수만큼 생성하는 방식. 새로운 버전의 Pod를 생성하고 기존 Pod를 제거한다. 무중단 배포라고도 한다. Deployment의 업데이트방식 기본값이다. maxUnavailable 롤링 업데이트 중에 사용할 수 없는 최대 파드의 수(=롤링 업데이트 중에 동시에 삭제할 수 있는 파드의 최대 개수) 퍼센트(%) 혹은 개수를 지정해줄 수 있다.(3으로 지정하면 기존 Pod 3개가 삭제, 10%로 지정하면 기존 Pod들의 10%가 삭제) maxUnavailable의 값을 높게 설정하면, 롤링 업데이트 시간이 줄어드는 대신, 기존 남아있는 Pod들에 Request수가 몰릴 수 있다. 따라서 1로 설정해서 Pod를 하나씩 ..

시스템이 사용하는 계정(사람이 쓰는 ID처럼 시스템이 쓰는 계정!) 시스템이 사용하는 계정 네임스페이스에 속하는 오브젝트다. 서비스 어카운트는 부여된 Role이외의 명령어는 실행할 수 없다. UserAccount ServiceAccount 주체 사람 파드에서 실행되는 프로세스 범위 클러스터 안의 모든 네임스페이스 특정 네임스페이스 특징 기업 데이터베이스로부터 동기화될 수 있다. 사람이 사용하는 것이기 때문에, 새 계정을 생성하려면 특별한 권한이 필요하며 복잡한 비즈니스 프로세스에 연결된다. 클러스터 사용자가 최소 권한 원칙에 따라 간단하게 만들 수 있다. 특정 작업을 위한 서비스 어카운트를 만들 수 있도록 보다 가볍게 만들어졌다. 1.각 네임스페이스에는 기본적으로 default라는 서비스가 자동생성된다...

컨테이너 단위에 limit 설정하기 request와 limit는 Pod가 아니라(!)컨테이너 단위에 정의된다. 하지만 Pod의 Request와 Limit은 포함된 컨테이너의 Request와 Limit의 합계로 생각할 수 있다. (오차 있음) Limit 값은 Request값보다 크거나 같아야 한다. 하나의 Pod에서 a컨테이너와 b컨테이너가 있다고 생각해볼 때, 해당 Pod는 서로 다른 Request와 Limit을 가진 컨테이너 2개를 가지게 되는 것이다!! Request보다 적은 Limit을 정의하려고 하면 쿠버네티스에서 해당 Pod를 생성하도록 허용하지 않는다. 장점 : Request와 Limit을 정의하는 것은 쉽다 단점 : 수많은 개발자들이 작업하는 대규모 클러스터에서는 Request와 Limit이..

쿠버네티스 apiVersion이란? 한줄 요약하면 오브젝트를 포함하는 API의 버전이다. apiVersion은 "group/version" 형태다. 쿠버네티스 버전에 따라 사용 가능한 apiVersion이 다르다. 일반적으로 alpha, beta 버전은 안정적이진 않지만, 그만큼 풍부한 기능을 갖고있기도 하다 쿠버네티스에서 사용 가능한 apiVersion은 kubectl api-versions 명령어로 확인할 수 있다. 오브젝트의 apiVersion 확인하는 방법 kubectl explain {오브젝트 종류} 예시 : kubectl explain cronjob 했을 때, 'VERSION: batch/v1' 이 cronjob의 apiVersion 이다. controlplane ~ ➜ kubectl expl..