![](http://i1.daumcdn.net/thumb/C148x148.fwebp.q85/?fname=https://blog.kakaocdn.net/dn/kHP5v/btqF2SHXaHE/4VXWiCIJTo2l40w7NAKJj1/img.png)
지금까지 Helm 사용법 및 Helm Customizing 방법에 대해 알아보았다. 자세한 내용은 아래를 참조한다. Helm3 기본 명령어 확인 및 Kubernetes deploy Helm3 Chart 커스터마이징 Helm의 사용법에 대해 알아보았으니, 이제 이를 활용한 Best Practice를 알아보고, 효과적으로 적용해 보도록 하자. 본 포스팅은 Helm 공식 사이트인 아래 URL을 참고하였다. https://helm.sh/ Helm Helm - The Kubernetes Package Manager. helm.sh 공통 규칙 1. Chart Name - Chart 이름은 소문자 + 숫자의 조합으로 구성되며, 두개 이상의 단어는 대시(-)로 구분한다. - Chart 이름은 대문자, 밑줄(_), 점(..
![](http://i1.daumcdn.net/thumb/C148x148.fwebp.q85/?fname=https://blog.kakaocdn.net/dn/dkuv61/btqFXg3ScaZ/3FkPofZqkZe5Jy53gFGm40/img.png)
"Helm Chart를 활용하여 MSA 기반의 복잡하고 많은 yaml 파일들을 관리하는 것은 당연하면서도 필수적인 방법이다. 이를 통해 유연한 변경관리, 버전관리, 즉각 대응, 가독성 향상, 불필요한 설정 파일 최소화 등 많은 이점을 가져갈 수 있다." 앞선 포스팅에서는 Helm3를 이용한 다양한 CLI 명령어 활용법과 Kubernetes에 배포하는 방법에 대해 알아보았다. 다시한번 확인하고 할 경우 다음을 참조한다. Helm3 기본 명령어 확인 및 Kubernetes deploy 이번 포스팅에서는 Helm 기반 실제 프로젝트 환경에서 chart를 관리하는 과정에 대해 본격적으로 살펴보도록 하자. helm chart 생성 chart를 생성하는 방법은 크게 2가지 방법이 있다. 하나는 helm create..
![](http://i1.daumcdn.net/thumb/C148x148.fwebp.q85/?fname=https://blog.kakaocdn.net/dn/csKtyq/btqFZOE5Pnn/ONc5SF4dVrY8GUxOvuKKUk/img.png)
"Helm은 Kubernetes의 yaml 파일을 관리하는 Chart 관리 매니저이다. 복잡한 Yaml 파일을 Chart 단위로 관리하며, Chart는 각 서비스 별 정의되는 value 파일을 기반으로 디플로이를 실행한다." helm을 기반으로 배포를 진행하기 위해서는 먼저 사전 준비해야 하는 작업이 있다. - kubernetes install - kubeconfig 파일을 로딩할 수 있도록 workstation server에 credential 구성 그럼 지금부터 Helm 3의 Chart 관리 프로세스에 대해 살펴보고 Kubernetes 배포 과정에 대해 알아보자. Helm 3 기본 명령어 Helm 3는 Chart라는 하나의 배포 단위를 생성하여 동일한 deployment를 갖고 있는 여러 서비스 집합..
![](http://i1.daumcdn.net/thumb/C148x148.fwebp.q85/?fname=https://blog.kakaocdn.net/dn/boLPJb/btqFnOfWjWL/8k6wAVoSORmZPUACOBizC0/img.png)
개요 본 포스팅에서는 Docker 이미지 빌드를 위한 Dockerfile 작성 시 유의할 3가지 종류의 태그에 대해 살펴보도록 하자. Dockerfile은 Docker Image를 생성하기 위한 Docker Container의 형태를 정의하는 Template이라 할 수 있다. Admin은 Dockerfile에 정의된 태그를 기반으로 Docker Image를 생성하며, Docker Image는 실제 Container 서비스로 동작하게 된다. 즉 Image를 어떻게 생성하느냐에 따라 서비스 형태가 달라지고 유지보수 효율성을 확보할 수 있는지 결정되기 때문에 이는 컨테이너 서비스를 제공하기 위한 중요한 고려사항이라 할 수 있다. Dockerfile을 작성하기 위한 요소 중 다음에서 다룰 3가지 사항은 비슷한 ..
![](http://i1.daumcdn.net/thumb/C148x148.fwebp.q85/?fname=https://blog.kakaocdn.net/dn/2tcrL/btqEPmYoBIJ/R02mylR7YiB4zKPKnUc7Z1/img.png)
개요 Kubernetes는 Pod 간 또는 다른 네트워크와 통신할 수 있도록 네트워크 Policy를 정의할 수 있다. Kubernetes는 네티워크 정책을 지정하기 위해 NetworkPolicy 리소스를 사용하며, Label을 사용하여 Pod를 지정하고 해당 Pod로 유입되는 모든 네트워크 트래픽을 구성한다. 네트워크 정책은 네트워크 플러그인으로 구현된다. Kuberentes 는 CNI와 Kubenet 네트워크 플러그인을 지원한다. Kubernete를 통해 구현되는 Pod는 기본으로 네트워크가 격리되지 않는다. 즉 Pod는 모든 네트워크에서 들어오는 유입을 허용한다. 이와 같이 유입을 모두 허용하는 Pod는 불 특정 요청에 노출되고 외부로 부터 침입 당할 수 있는 상태가 되어 보안에 유협받을 수 있다. ..
![](http://i1.daumcdn.net/thumb/C148x148.fwebp.q85/?fname=https://blog.kakaocdn.net/dn/bUK0vb/btqEOPfl8nn/KZWU4XASrIE9JtjKc34Jb0/img.png)
개요 Kubernetes는 인증(Authentication)과 인가(Authorization)를 통해 보안을 관리할 수 있다. 인증은 User에 대한 접속 허가 여부를 결정하는 방식으로 일반적인 사용자의 ID/Password 기반 로그인을 의미한다. 인가는 인증이 완료된 사용자가 특정 리소스에 접근하여 특정 액션을 수행할 수 있는지 여부를 결정하는 방식으로 로그인 후 admin 관리메뉴에 접근할 수 있도록 허가할 것인지, 특정 네임스페이스에 접근할 수 있도록 할 것인지 등의 경우를 의미한다. 본문 Kubernetes에서는 인증은 User Object에 부여되며, 인가는 User, Group, Service Account에 각각 부여할 수 있다. Kubernetes에서 의미하는 User, Group, Se..
![](http://i1.daumcdn.net/thumb/C148x148.fwebp.q85/?fname=https://blog.kakaocdn.net/dn/bjtDGI/btqEv71EMfg/dAbqjgya7xKDGXVxyk1Q20/img.png)
개요 컨테이너가 IT 시장을 잠식한지 벌써 수년이 흘렀다. 빠른 흐름의 변화에 따라 많은 프로젝트에서는 컨테이너 이미지를 적용하고 활용하고 있다. 특히 Docker는 대표적인 컨테이너 플랫폼으로 DockerHub라는 강력하고 다양한 이미지 레지스트리를 보유하고 있어 많은 사용자에게 Docker를 알리고 있다. 최근 흐름은 사실 Java와 맞먹을 정도의 인지로를 갖고 있다고 할까나.. 이러한 강력한 Docker Container를 활용하고 있지만, 한가지 심각한 문제점을 갖고 있다. 바로 컨테이너 이미지는 누가 작성한 것이고 어떻게 작성한 것인지 파악하기 어렵다는 점이다. 물론 Dockerfile 정보와 DockerHub의 Manifest 정보를 활용할 수도 있지만, 여전히 어떠한 파일이 사용되었는지는 알..
![](http://i1.daumcdn.net/thumb/C148x148.fwebp.q85/?fname=https://blog.kakaocdn.net/dn/MXlU1/btqD6QFnjz7/dpdd57NYkG0Q7KluSmNRAK/img.png)
개요 마이크로서비스 아키텍처는 독립적으로 배포 및 확장 될 수 있는 서비스(Loosely Coupled)들을 조합하여 하나의 애플리케이션을 완성하는 아키텍처이다. 마이크로서비스를 적용하면 빠른 배포 주기와 장애 확산 차단, 대용량 분산환경 시스템 구축, 폴리그랏 프로그래밍 적용 등의 장점을 얻을 수 있으며, 최근 아니 2~3년 전부터 빠르게 Enterprise IT시장을 잠식해 나가고 있는 핫한 아키텍처라 할 수 있다. 마이크로서비스 아키텍처를 통해 분해된 서비스는 경량화 기반 민첩성/유연성을 보장하고, 확장성을 제공하며, 장애 탄력성을 통한 복구전략을 수립하는 등 Container Management Platform과 상통하는 아키텍처 방식으로 많은 주목을 받고있다. 다만 마이크로서비스 아키텍처는 In..
서론 본 포스팅에서는 쿠버네티스에서 포드 기동 장애 발생 시 트러블슈팅에 활용할 수 있는 유용한 명령어에 대해 살펴본다. 쿠버네티스에서는 포드의 장애 발생 시 kubectl logs, kubectl describe 등의 명령어를 사용하여 어느 정도 수준은 분석이 1차로 가능하다. 다만 logs가 발생되지도 않으면서 describe에 표출되는 정보 역시 무관하거나, 막연한 정도의 수준으로 표출되는 경우 포드의 상태를 검증하는데 어려움이 있을 수 있다. 이때 포드 기동 문제를 검증하기 위해 아래와 같은 3가지 유용한 명령어를 활용하여 트러블슈팅을 진행할 수 있다. 본론 1) kubectl edit deployment [deployment_name] 먼저 kubectl edit를 활용하는 방법이다. 다음은 현..
![](http://i1.daumcdn.net/thumb/C148x148.fwebp.q85/?fname=https://blog.kakaocdn.net/dn/c6RycI/btqCDkhwJLm/pfgWhTm2mbR5cvYJQxL3Mk/img.png)
도커 이미지를 사용하여 빌드/배포를 수행하면, 버전 관리, 동일한 환경 항상 유지, 이관 편의성 등 다양한 장점을 갖고 있다. 이러한 이유로 도커 이미지는 도커 컨테이너로 기동되고 빌드/배포 자동화를 통해 손쉬운 개발 환경으로 사용되고 있다. 다만, 도커 이미지의 관리를 위해, 퍼블릭 공간의 DockerHub, 프라이빗 공간의 Docker Registry (Nexus3, Docker Image 등)는 무한으로 확장 가능한 공간을 제공하지는 않는다. 이로 인해 불필요한 이미지를 삭제하고 리소스 공간을 확보하는 것이 중요하다. 이미지의 경량화는 사실상 클라우드 환경에서 확장성과 민첩성을 높이기 위해 매우 중요한 요소이지만, 작은 이미지라도 500MB, 1GB 수준의 파일들이 매 빌드, 매 배포 마다 누적 된..
- Total
- Today
- Yesterday
- Architecture
- node.js
- kubernetes
- Da
- openstack tenant
- apache
- 마이크로서비스
- wildfly
- openstack token issue
- 마이크로서비스 아키텍처
- TA
- JEUS7
- JBoss
- jeus
- nodejs
- k8s
- SWA
- aws
- webtob
- Docker
- aa
- MSA
- JEUS6
- SA
- git
- 오픈스택
- 아키텍처
- API Gateway
- 쿠버네티스
- OpenStack
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |