일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |
- 소셜로그인
- 스프링부트
- 토이프로젝트
- docker
- 국제화
- 오블완
- 리프레시토큰
- CI/CD
- 재갱신
- 티스토리챌린지
- 백준
- springdataredis
- 데이터베이스
- 트랜잭션
- 액세스토큰
- 스프링
- java
- 도커
- Spring
- springsecurityoauth2client
- oauth2
- springsecurity
- AWS
- 프로그래머스
- 파이썬
- yaml-resource-bundle
- 메시지
- githubactions
- JIRA
- 스프링시큐리티
- Today
- Total
목록DevOps/Kubernetes (7)
땃쥐네

쿠버네티스로 애플리케이션을 운영, 관리하다보면 대부분의 문제는 파드에서 발생한다. 유지/보수 관점에서는 대부분의 시간을 결국 파드에서 발생하는 문제를 해결하는데 써야하는데, 이를 디버깅하는 방법을 알아둘 필요가 있다.파드(Pod)가 정상적으로 실행되지 않았을 때 보통 파드 관련 문제는파드 실행 이전, 파드 실행 이후 파드 내부 컨테이너가 죽거나 에러가 발생하는 경우 두 가지로 나뉠 수 있다. 파드 실행 이전 단계에서 문제가 터지면, 파드 자체에 접속하는 것도 불가능하다. redis-pod.yamlapiVersion: v1kind: Podmetadata: name: redis-podspec: containers: - name: redis-container image: redis:v1234..

이전 글에서는 파드를 생성하여 외부에서 접속하는 방법을 다뤄봤는데예시가 부족하므로 스프링부트 파드를 추가적으로 실행해 접속해보도록 할 것이다.스프링부트 프로젝트 생성 Spring Initializr 를 통해 Spring Boot 프로젝트를 생성해봤다.Project 는 Gradle - Kotlin 으로, Language 는 Kotlin, Spring Boot 버전은 SNAPSHOT 이나 M2가 아닌 최신 버전Dependencies 로는 Spring Web 을 설정했다. Java 버전은 21 Generate 버튼을 클릭해 생성되는 압축파일을 풀어서 프로젝트를 생성한다. 압축을 풀면 이런 폴더가 생성되는데 이 경로를 IntelliJ 를 통해 열어서 수정한다. package hello.exampleimpo..

파드를 실행했으나 접속할 수 없음 지난 글에서, tomcat 파드를 8080 포트에서 실행을 했으나 localhost:8080 으로 접근 불가능한 문제가 있었다.왜 이 주소로 접속했을 때 tomcat 에 접속할 수 없는 지 문제의 원인을 파악하고, 해결해봐야한다. 무엇이 문제의 원인인 지는, 파드 내부와 쿠버네티스 네트워크의 관계에 대한 이해가 먼저 필요하다. 파드와 쿠버네티스 네트워크 각 파드는 하나의 고유한 IP 주소를 가지고 있고, 이 IP는 해당 파드 내의 모든 컨테이너가 공유한다.이들은 같은 호스트네임을 공유한다. 이들 컨테이너는 동일한 IP 주소를 사용하여 서로 통신하므로, 내부망에서 통신한다고 할 수 있다. 그런데, 파드 내의 컨테이너들은 동일한 IP를 공유하므로, 각 파드내에서 동일한 포..

파드를 생성하는 방법파드를 생성하는 방법은 크게 두 가지로 나뉘어진다. 하나는 CLI 명령을 통해 직접 파드 생성 명령을 기술하는 방식이고,다른 하나는 파일(보통 yaml 파일)을 통해 파드에 대한 명세를 기술하고 이 파일을 통해 파드를 실행시키는 방법이다. 그러나 보통 파드 하나를 실행시키기 위해 설정해야하는 값들은 많고 이를 CLI 명령을 통해 매번 실행, 관리하는 것은 유지보수 관점에서 좋지 않으므로 재사용의 편의를 위해, 파일을 통해 파드를 생성한다.매니페스트 파일(Manifest File)위에서 파드는 파일을 통해 생성한다고 말했는데, 파드뿐만 아니라 쿠버네티스의 다양한 리소스(파드, 서비스, 디플로이먼트, 볼륨, ...) 등을 생성할 때도 파일을 사용해서 생성한다. 이런 리소스들을 생성하는 파..

파드란 파드는 쿠버네티스에서의 애플리케이션 실행의 최소 단위이다. 도커에서는 애플리케이션 실행을 '컨테이너' 단위로 관리한다면,쿠버네티스에서는 애플리케이션 실행을 '파드' 단위로 관리한다. 다시 말해, 쿠버네티스는 컨테이너를 개별적으로 배포하지 않고, 파드 단위로 배포하고 운영한다. 일반적으로 하나의 파드가 하나의 컨테이너를 가지게 파드를 설계한다. 물론 위의 그림과 같이 파드 한 개에 컨테이너 2개를 두는 식으로 운영이 가능하긴 하다.그러나 이렇게 파드를 설계하는 경우는 두 파드가 밀접하게 연관된 프로세스인 경우에만 해당한다. 둘의 목적이 아예 다른 경우(예: 프론트엔드 서버 - 백엔드 서버, 결제 서버 - 회원 서버, ...) 는 보통 파드를 따로 분리한다. 파드 = 서버 결국 우리 애플리케이션은..

이번 글에서는 Windows 로컬환경에서 편리하게 쿠버네티스를 간단하게 사용해 볼 수 있도록 해보겠습니다. 왜 로컬 환경에 쿠버네티스를 설치할까?실무에서는 개발자들이 쿠버네티스를 직접 설치할 일이 드문 것으로 알고 있다.보통 AWS EKS 와 같은 클라우드 서비스를 많이 활용하고, 이런 부분은 쿠버네티스에서 환경구성을 해주기 때문이다. 하지만 개발자 입장에서는 로컬 환경에서 쿠버네티스 테스트를 위해 쿠버네티스를 사용할 필요가 있고,실제 클라우드 환경의 쿠버네티스에 명령을 내릴 수 있어야한다. 이런 여러가지 이유로, 로컬 환경 쿠버네티스 설치가 필요하다. 도커 데스크탑을 통해 쿠버네티스 설치하기보통 프로덕션 환경에서 쿠버네티스를 구축하는 것은 매우 복잡한 일인데(최소 세대 이상의 컴퓨터가 필요하고 여러가지..

이번 글에서는 쿠버네티스 기술이란 어떤 기술인지, 왜 도입됐는지, 무엇을 할 수 있는 지 이야기합니다.도커 기술 도커 기술은 애플리케이션을 컨테이너 단위로 독립시켜 실행할 수 있도록 해준다. 우리 애플리케이션을 '이미지'라는 형태로 구성하고, 이 이미지를 기반으로 여러 대의 '컨테이너'들을 실행하는 형식으로 관리할 수 있게 한다. 도커 기술을 사용하면 우리는 동일한 애플리케이션을 여러 환경에 배포할 때 매번 환경을 새로 구성하지 않고, 그저 이미지를 기반으로 컨테이너 형태로 편리하게 애플리케이션을 실행시킬 수 있게 한다. 언제든 편할 때 컨테이너를 실행시키고, 죽이는 식으로 애플리케이션 서비스를 운영할 수 있게 된다. 이 기술은 여러 웹 서비스들의 운영 관리 관점에서 혁신이였고, 지금도 현업에서 주로 사..