# kubenetes

lee_yesol421

책: 컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커 - 3장 컨테이너를 다루는 표준 아키텍처, 쿠버네티스 인프런 강의 : 쉽게 시작하는 쿠버네티스(v1.25) - 쿠버네티스 환경 구성 쿠버네티스 이해하기 vagrant로 테스트 환경 설정 저자의 github에서 제공하는 Vagrantfile을 다운로드받아 vagrant up으로 마스터노드 1개, 워커노드 3개로 구성된 가상머신 테스트환경을 구축하였다. 파드 배포하기 Kubernetes — Architecture Overview (이미지 : [Kubernetes — Architecture Overview](https://medium.com/devops-mojo/kubernetes-architecture-overview-int

lee_yesol421

책: 컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커 - 2장 테스트환경 구축하기 인프런 강의 : 쉽게 시작하는 쿠버네티스(v1.25) - 쿠버네티스 환경 구성 쿠버네티스는 기본적으로 다수의 서버를 관리하는 도구이기 때문에 연습하기 위해서 가상머신으로 여러 대의 노드를 구성한다. 2장에서는 virtualbox 가상머신을 이용하여 1개의 마스터노드와 3개의 워커 노드로 구성된 테스트 환경을 준비한다. virtualbox로 테스트 환경 구성하기 환경 구성 도구 virtualbox : 가상머신을 구성할 수 있는 가상화 소프트웨어. vagrant(베이그런트) : 코드로 인프라 설정을 미리 작성해두고 실행하면 해당 설정으로 인프라를 만들어주는 소프트웨어. 프로비저닝(provisioning) 툴 자주 사용하는 vagrant 명령어 vagrant init: 프로비저닝을 위한 기초 파일인 Vagrantfile 생성 vagrant init:

jimmy0006

해당 글은 그림과 실습으로 쉽게 배우는 도커&쿠버네티스 책을 요약 정리한 글입니다. 도커? 도커는 데이터 혹은 프로그램을 격리시키는 기능을 제공한다. 서버에 여러 가지 프로그램이 함께 동작할 때, 다양한 프로그램과 데이터를 운영체제 통째로 격리시킨다. 컨테이너와 도커 엔진 작게 작은 창고가 컨테이너고, 이 컨테이너를 다루는 소프트웨어가 도커이다. 이미지? 컨테이너를 만들려면 도커 엔진과 이미지가 필요하다. 이미지는 컨테이너의 빵틀과도 같은 역할을 수행한다. 도커는 리눅스에서 사용한다. 윈도우, macOS에서도 도커를 구동할 수 있지만, 내부적으로 리눅스가 사용된다. 도커가 필요한 이유? 대부분의 프로그램은 실행 환경이나 라이브러리, 다른 프로그램을 이용해 동작한다. 다른 프로그램과 특정한 폴더 및 디렉터리를 공유하거나 같은 경로에 설정 정보를 저장하는 경우도 있다. 각자 따로 실행하면 동작하는 프로그램들이 같이 실행하면 오류가 나는 경우가 있다. 이

hyeokjinon

쿠버네티스 클러스터에서 실행되는 애플리케이션을 업데이트 하는 방법과 쿠버네티스가 어떻게 무중단 업데이트 프로세스로 전환하는 데 도움을 주는지 살펴보자 쿠버네티스는 레플리카셋 기능을 활용하는 디플로이먼트 리소스를 제공해 선언적인 애플리케이션 업데이트를 가능하게 한다. 애플리케이션을 선언적으로 업데이트하기 위한 디플로이먼트 사용하기 디플로이먼트는 낮은 수준의 개념으로 간주되는 레플리케이션컨트롤러 또는 레플리카셋을 통해 수행하는 대신 애플리케이션을 배포하고 선언적으로 업데이트하기 위한 높은 수준의 리소스다. 실제 파드는 디플로이먼트가 아닌 디플로이먼트의 레플리카셋에 의해 생성되고 관리된다. 디플로이먼트 생성 디플로이먼트를 생성하는 것은 레플리케이션컨트롤러를 만드는 것과 다르지 않다. 레이블 셀렉터, 원하는 레플리카 수, 파드 템플릿으로 구성된다. 또한 디플로이먼트 리소스가 수정될 때 업데이트 수행 방법을 정의하는 디플로이먼트 전략을 지정하는 필드도 있다. > kub

hyeokjinon

빌드/배포 파이프라인 인 액션 O-stock 서비스의 빌드/배포 파이프라인을 구현하는 데 사용할 다양한 기술을 먼저 그림으로 살펴보자 깃허브 : 소스 코드에 대한 소스 제어 저장소다 깃허브를 빌드 프로세스에 통합하는 다양한 웹훅과 강력한 REST 기반 API를 제공하기 때문에 깃허브를 소스 제어 저장소로 선택했다. 젠킨스 : O-stock 마이크로서비스를 구축 및 배포하고 도커 이미지를 프로비저닝하는 데 사용되는 지속적 통합 엔진이다. 젠킨스는 웹 인터페이스로 쉽게 구성할 수 있으며, 작업을 더 쉽게 만들어 주는 몇 가지 내장 플러그인이 포함되어 있다. 메이븐/스포티파이 도커 플러그인 또는 스프링 부트 도커 : 자바 코드를 컴파일, 테스트, 패키징하는 데 바닐라 메이븐을 사용했지

yukina1418

CI/CD를 설정하고 난 다음날, 프론트엔드에서 작업을 하는데 에러가 발생했다고 알려줬다. gcp.json 파일이 존재하지 않습니다. 이미지 업로드를 위하여 계정 정보가 들어가있던 json 파일이 존재하지 않는단다(....) >왜 그런지 고민을 해봤더니 CICD 설정하기 전 날 이런 일이 있었다. 원래는 시크릿 설정을 해서 사용하던 것이 문제가 생겨서 그냥 로컬에서 바로 빌드 푸시를 해서 배포를 했던 적이 있었는데 정상작동을 해서 아 이렇게 써도 상관 없겠구나 하고 넘겼던 것이었다. 하지만 CI/CD를 사용하는 GCP의 Cloud build는 깃허브 저장소를 기준으로 자동배포가 이루어진다. 그러나 계정에 대한 정보가 들어가있는 json 파일을 깃허브에 올리면 해킹을 하여 코인 채굴에 쓰는 해커들 덕분에 프로젝트가 잠기게 되는데 이 때문에 json 파일은 .gitignore에 적어서 업로드가 되지 않도록 방지를 하는 것이 필수다. 그렇기

codingdaddy

AWS Ubuntu (c5.xlarge) 에 AWX 19를 설치하는 방법을 공유한다 인프라 준비 Ubuntu 20.04 깡통 Ec2 생성 Security 그룹 생성 Target Group 생성 + Ec2 추가 NLB 생성 + Target Group 추가 Route53 도메인 생성 + NLB 연결 도메인 준비(필요시): sre-awx.mysite.io 1. Ubuntu 업데이트 2. k3s kubernetes 설치 3. AWX Operator 배포 on Kubernetes 3.1 git 설치 3.2 Clone operator deployment code 3.3 Create namespace where operator will be deployed : awx 3.4 Set current context to value set in NAMESPACE variable 3.5

choiys0212

쿠버네티스 아키텍처 개요 쿠버네티스를 배포하면 클러스터를 얻는다. 클러스터는 컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커머신의 집합으로 한개 이상의 워크 노드를 가진다. 클러스터에는 Control Plane, Woker Node, 애드온이 존재한다. 워크노드 : 애플리케이션의 구성요소인 Pod를 호스트 컨트롤 플레인 : 클러스터 스케줄링 등 전반적인 것들을 수행하고 클러스터 이벤트를 감지하고 반응 애드온 : 클러스터 기능을 구현하기 위해 클러스터 단위 기능을 제공 Control Plane이란? 컨테이너의 라이프사이클을 정의, 배포, 관리하기 위한 API와 인터페이스들을 노출하는 컨테이너 오케스트레이션 레이어로 이 계층은 다양한 컴포넌트로 구성된다.(제한되는 것은

bonjaski0989

블로그 이전 안내 > 더 높은 가독성과 고품질의 글을 작성하기 위해 티스토리로 이전하였습니다. https://anggeum.tistory.com/entry/Kubernetes-Volume-Deep-Dive 개요 Pod는 내부에 프로세스가 실행되고 CPU, RAM, 네트워크 인터페이스 등의 리소스를 공유하는 논리적 호스트와 유사하다. Pod 내부의 각 컨테이너는 고유하게 분리된 파일시스템을 가진다. (파일시스템은 컨테이너 이미지에서 제공되기 때문이다.) 특정 Scenario에서는 물리 머신에서 Process를 다시 시작하는 것과 같이 새로운 컨테이너가 이전에 종료된 위치에서 계속되기를 원할 수 있다. 즉, Stateful한 Application 경우(Pod, Deployment) 데이터를 영속적으로 저장하기 위한 방법이 필요하다. Storage Volume 쿠버네티스는 Storage Volume을 정의하는 방법으

pocosloth

Rancher Logo Rancher란 무엇인가? Rancher는 컨테이너 워크로드를 보다 쉽게 관리할 수 있도록 도와주는 멀티 클러스터 관리 플랫폼입니다. 1.x 버전에서는 Swarm, Kubenetes, Mesos와 같이 다양한 컨테이너 오케스트레이션을 지원했지만 2.x 버전에서는 사실상 표준이 된 Kubenetes만 지원을 하고 있습니다. Rancher 1.x 출처: https://rancher.com/docs/rancher/v1.6/en/ Rancher 1.x Rancher 2.x 출처: https://rancher.com/docs/rancher/v2

wickedev

깃랩(Gitlab)은 온프레미스 설치형 깃 호스팅으로 유명하고, 깃헙처럼 웹서비스 형태로도 사용이 가능합니다. 다만 깃헙이 선점 효과를 톡톡히 누리고 있는지라 만년 2인자 자리를 지키고 있죠. 깃랩의 장점이라면 CI/CD가 잘되어 있습니다. 심지어 설치형이 아니라도 public 레포인 경우 무료, private 레포인 경우 그룹 당 월 2000분(약 33.3시간)까지 무료입니다. 유료 플랜까지 가게되면 깃랩 안에서 모든걸 다 처리하라고 왠만한 솔루션 뺨치는 쿠버네티스 관리 보드까지 달아줍니다. 최근 깃헙도 이에 질세라 깃헙 액션을 베타로 공개했지만, 아직까지는 Circle CI, Travis CI 같은 외부 서비스를 사용하는게 일반적이죠 큰 그림을 보자면 깃랩의 CI/CD는 도커에서 돌아갑니다. 그리고 연결된 쿠버네티스에 배포됩니다. 프로젝트 루트에 .gitlab-ci.yml이 있는 상태로 새로운 푸시가 들어오면 일련의 파이프라인(Job 묶