Fairy ' s

지금까지 Pod, Deployment, Service 같은 오브젝트들을 생성했는데, 우리는 지금까지 이것들을 하나의 NameSpace 안에서 만들었고, 항상 우리는 NameSpace라는 집 안에 있었다고 할 수 있다. 이러한 namespace들은 누가 무엇을 할 수 있는지 정의하고, 리소스를 사용량을 할당하는 고유한 정책을 가질 수 있다. 리소스 사용량을 할당하면 각 namespace가 허용 한도 이상의 리소스를 사용하지 않게 된다. 쿠버네티스가 자동으로 생성하는 namespace는 세 가지가 있다. 첫 번째는 kube-system으로 클러스터가 시작될 때 생성된다. 두 번째는 kube-public 으로 이 곳은 모든 사용자가 자원을 사용할 수 있어야 한다. 세 번째는 default namespace이다..

어떠한 애플리케이션에 다양한 섹션을 실행하는 파드의 그룹들이 있다. 예를 들어 프론트를 유저에게 서빙하는 그룹, 백엔드 프로세스를 실행하는 그룹, 외부 데이터 소스에 연결하는 그룹 등이 있을 것이다. 이러한 파드 그룹 간 연결을 가능하게 하는 것이 Service이다. Service를 통해 프론트 애플리케이션을 엔드 유저가 사용할 수 있게 하고, 백엔드와 프론트 파드 간의 통신을 돕고, 외부 데이터 소스 연결 설정에 도움을 준다. 즉, Service는 애플리케이션의 마이크로서비스 간에 느슨한 연결을 가능하게 한다. Service 웹 애플리케이션이 실행되고 있는 파드를 배포 했을 때, 외부 사용자가 어떻게 웹 페이지에 접속할 수 있을까? 파드와 자신의 네트워크가 다른 IP에 있으면 파드에 ping을 하거나 ..

Yaml file을 만들고 편집하는 것은 CLI 환경에서 포함 다소 어려운 편이다. kubectl run 명령을 사용하면 YAML template을 생성하는 데 도움이 될 수 있다. 예를 들어 특정 이름과 이미지를 사용해 파드나 Deployment를 생성하라는 요청을 받았을 때에는 간단하게 kubectl run 명령으로만 해결이 가능하다. # Create NGINX Pod $ kubectl run nginx --image=nginx # Simulates the creation Pod running the 'NGINX' container $ kubectl run nginx --image=nginx --dry-run=client -o yaml # Create a Deployment $ kubectl crea..

애플리케이션이 담긴 컨테이너는 파드에 캡슐화된다. 파드 여러 개를 동시에 사용하도록 보장해주는 역할로 ReplicaSet을 사용했다. 오늘 배우게 될 Deployment는 ReplicaSet보다 한 단계 더 높은 계층 구조에 있다. (Deployment 생성 시 ReplicaSet 자동 생성) Deployment 우리에게 배포해야 할 웹 서버가 있고, 웹 서버의 인스턴스가 많이 필요한 상황이다. 그리고 애플리케이션의 새 버전이 나올 때마다 Docker 인스턴스를 원활하게 업그레이드 하고 싶을 때, 모든 인스턴스를 한번에 업그레이드 할 경우 유저에게 영향을 미칠 수 있다. 이러한 업그레이드를 '롤링 업데이트' 라고 하는데, 만약 업그레이드를 하다 오류가 발생하면 최근 변경 사항들을 '롤백' 해야 할 것이다..

컨트롤러는 쿠버네티스의 두뇌이며, 쿠버네티스 오브젝트를 모니터링하고 반응하는 프로세스이다. 애플리케이션을 실행하는 단일 파드가 있고, 그 애플리케이션과 파드가 죽었다면, 유저는 더 이상 애플리케이션에 접근할 수 없다. 이러한 상황에서도 유저가 애플리케이션에 접근 권한을 잃지 않도록 하고 싶고, 동시에 실행되는 둘 이상의 인스턴스 또는 파드를 가지고 싶을 때, Replication controller가 도움이 된다. Replication Controller 클러스터에서 파드의 여러 인스턴스를 실행하는 데에 도움이 되며, 이는 곧 고가용성을 제공한다고 할 수 있다. 만약 파드 한 개만 사용할 예정이어도 Replication contoller가 도움이 될 수 있다. Replication contoller는 기..

쿠버네티스에서의 궁극적인 목표는 워커 노드로 구성된 컨테이너 형태로 애플리케이션을 배포하는 것이다. 그러나, 쿠버네티스는 컨테이너를 워커 노드에서 직접 배포하지 않는다. 컨테이너들은 Pod라는 쿠버네티스 오브젝트로 캡슐화 되어 있다. Pod 파드는 애플리케이션의 단일 인스턴스이며, 쿠버네티스에서 만들 수 있는 가장 작은 단위이다. 기본적으로 파드의 컨테이너는 동일한 스토리지, 동일한 네트워크 네임스페이스에 액세스 권한을 갖는다. 또한 파드의 컨테이너들은 함께 생성되고 함께 파괴된다. 쿠버네티스 클러스터에 하나의 노드가 있고, 노드 안에서 애플리케이션 인스턴스 하나가 도커 컨테이너로 캡슐화된 파드에서 실행되고 있다. 만약 애플리케이션에 접속하는 유저 수가 증가해서 애플리케이션을 확장해야 한다면, 트래픽을 ..

Infrastructure as Code, 즉 코드로써의 인프라는 인프라를 이루는 서버, 미들웨어 그리고 서비스 등, 인프라 구성요소들을 코드를 통해 구축하는 것이다. IaC는 코드로써의 장점, 즉 작성용이성, 재사용성, 유지보수 등의 장점을 가진다. Terraform by Hashicorp 테라폼은 인프라를 만들고, 변경하고, 기록하는 IaC를 위해 만들어진 도구로써, 문법이 쉬워 비교적 다루기 쉽고 사용자가 매우 많아 참고할 수 있는 예제가 많다. AWS, Azure, GCP 같은 퍼블릭 클라우드 뿐 아니라 다양한 서비스들을 지원한다. 구성 요소 provider 테라폼으로 생성할 인프라의 종류 resource 테라폼으로 실제 생성할 인프라 자원 state 테라폼을 통해 생성한 자원의 상태 output..

개발팀과 운영팀 생각의 차이에 대해 인지하고 그 간극을 줄여보자는 이야기에서 시작되었다. 이러한 생각이 지속적으로 발전을 거듭해서 현재는 소프트웨어 개발, 우리의 일에 관한 포괄적인 철학과 방법론이 되었다. 5가지 철학 문화 (Culture) : DevOps를 통해 하나의 문화를 만들어 나간다. 사람 : 팀, 인원, 가치, 의사소통 일 : 프로세스, 방법론 서비스 : 서비스의 가치, 성격 자원 : H/W, S/W 기술, 도구 시간 : 일정에 따른 변경 가능성, 회복 탄력성, 예측 자동화 (Automation) : 자동화를 통해 효율성과 빠른 속도를 지향한다. 인프라 및 보안 : 클라우드, 네트워크, 접근제어, 암호화 언어 및 도구 : 프로그래밍 및 도구 지속적 통합 / 배포 : CI/CD 파이프라인 구성..