네른

보통 로깅을 위한 아키텍쳐라고 하면 ELK(Elasticsearch, Logstash, Kibana)의 구조를 생각하게 된다. 가장 유명한? 널리 알려진? 로깅/분석 스택이기 때문이다. Kubernetes 환경에서도, Kubernetes 자체의 로그 뿐 아니라 내부의 애플리케이션에 대한 로깅과 매니징이 필요하다. 그래서 사내에서 동작중인 앱에 대해 ELK 스택을 적용하고자 하였으나, CNCF stack을 찾아보니 Logstash보다는 Fluentd를 권장하고 있어 이를 사용하게 되었다. Fluentd에 대해 간단히 설명하자면 다음과 같다 - 오픈소스 기반의 로그 수집기 - HTTP, TCP, File 등 다양한 데이터 소스로부터 로그를 수집해 원하는 곳으로 전달(elasticseardch, s3)할 수 ..

본 글에서 알아볼 내용은, 쿠버네티스에서 환경변수, conf 파일 등을 어떻게하면 효율적으로, 편하게 사용하는지에 대한 내용. 실제 kubernetes를 이용하게 되면, 만약 conf 파일이 Pod 내에 있는 경우 이를 수정할 방법이 마땅치 않거나 매우 복잡. 그래서, 이를 조금 더 쉽게 하는 대표적인 두 리소스가 configMap과 secret. - 환경변수 혹은 설정파일을 일종의 변수로 두고 Pod가 생성될 때(배포될 때) 반영할 수 있도록! - 방법은 크게 두 가지로, 환경변수(env) 혹은 disk mount의 방법 ConfigMap - Key-Value 형태로 데이터를 저장할 수 있음 kind: ConfigMap apiVersion: v1 metadata: name: common-config n..

기존의 서비스들은 가용성을 유지하면서 애플리케이션을 업데이트하기 위해 블루-그린 업데이트 등의 방식을 사용해왔음. kubernetes에서는 이러한 업데이트를 '롤링 업데이트' 방식으로 처리함. - ReplicaSet 단위로 진행되며, 기존 ReplicaSet의 replica 수를 줄임과 동시에 새 ReplicaSet의 replica 수를 늘려서 유지되도록 이러한 과정을 추상화해두고, 이용하기 쉽게 해둔것이 바로 Deployment. 앞서 말했던것과 같이, deployment는 ReplicaSet의 추상화된 개념임을 유의 실제 deployment를 배포한 후, 다음과 같은 명령어로 기존 replicaset을 업데이트 할 수 있다. $ kubectl set image deployment DEPLOYMENT이..