Study

객체를 다루다보면, 특정 객체를 복사해서 사용하는 경우가 종종 있다.보통 이 과정에서는 단순하게 아래처럼 사용하고는 한다.num = 150num2 = numprint(num2) # 150 DFS와 백트래킹 관련 알고리즘 문제를 풀던 중 입력된 field(이중 list)를 복사해두어서 백트래킹 과정에서 사용했었다.이 과정에서 단순하게 복사를 해서 사용했고, 의도대로 백트래킹 로직이 돌지 않았다는 것을 확인했다.그리고 원인 파악에서 복사한 이중 list에 대한 원본이 계속 수정되고 있다는 것을 알게 되었다. 이 과정에서 Python의 얕은 복사와 깊은 복사에 대해 알게 되었고, 이를 정리하고자 한다. 얕은 복사(Shallow Copy)새 객체를 생성하지만 원본에 포함된 객체에 대한 참조를 유지하는 방식..

HTTPSHTTPS는 HTTP 프로토콜상에 SSL 레이어를 추가한 통신 프로토콜로, 암호화된 HTTP 통신 프로토콜이다.서버와 클라이언트 간의 통신에서 중간에 악성 행위자로 하여금 데이터가 가로채어지거나 변조되지 않도록 하는 데이터의 전송과정에서의 보안 요소로, 기밀성과 무결성을 보장한다. SSL 인증서SSL/TLS 프로토콜을 이용해 다른 시스템에 암호화된 안전한 연결을 수행할 수 있도록 하는 디지털 객체SSL 인증서는 주로 웹 서비스와 사용자 간에 신뢰할 수 있는 통신을 위해 사용된다. SSL 인증서는 제3 인증기관(CA)이 발급해주며,  브라우저의 URL 좌측에서 HTTPS로 연결된 사이트에 대한 SSL 연결과 그 인증서 내용을 확인할 수 있다.  근래 거의 대부분의 웹 사이트에는 HTTPS를 사용해..

일반적으로 kubernetes 클러스터 pod의 Metric을 모니터링하기 위해 Prometheus를 구축을 하게된다.운영되는 서비스와 범위가 확장됨에 따라 Prometheus가 모니터링할 대상의 갯수도 증가하게 되는데, 이에 따라 Prometheus에 가해지는 부하가 증가하게 될 것이다. 이러한 Prometheus의 몇 가지 한계점은 아래와 같이 정리될 수 있다.문제점내용확장성 제한기본적으로 Prometheus는 단일 서버 구성을 전제로 설계되어있어 수평적 확장에 어려움이 존재한다.SPoF(Single Point of Failure) 문제Prometheus를 단일 서버로 운영하게 되는 경우, 해당 노드에 장애가 발생하면 Metric 수집이 불가해 모니터링이 불가능하다.HA(High Availabilit..

Kubernetes에는 Secrets라는 리소스가 존재한다. Secrets에는 Application에서 사용하는 Credential과 같은 민감한 정보를 저장하여 관리하도록 한다.하지만 Secrets은 이름과는 다르게 정말 완벽한 비밀은 아니다. 이러한 Secrets는 Kubernetes 클러스터 Control plane에 위치한 etcd에 저장되는데, base64로 인코딩된 값이 평문으로 그대로 저장되기 때문이다. Secrets를 정말 Secret답게 사용하기 위해 보통 크게 3가지 방법을 사용하는 것이 제시된다.RBAC를 활용해 Secrets에 접근할 수 있는 User를 제한하는 방법외부 Secret Management 서비스를 이용해 저장 후, 클러스터로 가져와서 사용하는 방법Secrets가 저장되..

EC2 인스턴스내에서 AWS 서비스에 접근하기 위해서는 IAM User의 AccessKey Credential을 가져와서 사용하거나, 인스턴스에 IAM Role을 지정한 뒤 사용하고는 했다.그렇다면 Kubernetes의 클러스터에 존재하는 pod에서는 어떨까? pod 내에서도 마찬가지로 IAM User의 Credential을 넣고 사용하는 방법도 가능하다. 하지만 이러한 방법이 정말 안전하다고 말할 수는 없다.IAM User의 AccessKey Credential은 탈취의 위협이 항상 존재하므로 Application내에 하드코딩하거나 Application 구동 환경의 환경변수 등에 삽입하여 사용하는 것은 권고되지 않는 방식이다. 이런 문제를 위해 EC2 인스턴스에 연결하는 IAM Role이 존재한다. 하..

EBS CSI Driverkubernetes 클러스터와 AWS EBS 서비스의 연동을 위한 드라이버로, AWS EBS를 Storage로써 사용하기 위해 설치한다.EKS 클러스터에 PV를 프로비저닝, 마운트 작업을 수행하고, StorageClass를 이용해 EBS 볼륨을 동적으로 생성/삭제(Dynamic Provision)하는 역할을 수행한다. EBS CSI Driver는 다음과 같은 특성을 가진다.생성한 EBS의 PVC AccessMode는 ReadWriteOnce로 구성 EBS는 node(EC2)와 1:1로 매핑되는 구성을 갖기에, 동시에 같은 EBS에 접근 불가동시에 여러 액세스가 필요한 상황에서는 EBS가 아닌 EFS를 사용할 수 있다. EBS가 위치한 가용영역으로 PV의 nodeAffinity를 ..

이번에는 kOps를 통해 생성한 클러스터에 LoadBalancer와 Ingress를 각각 생성해보도록 한다.LoadBalancer와 Ingress 서비스는 AWS 클라우드 환경에 배포하는 경우 각각 NLB, ALB와 연동이 된다.즉, 모두 AWS 로드밸런서 서비스(ELB)와 연결이 된다고 볼 수 있다. 클러스터의 서비스를 이러한 클라우드 로드밸런서와 연결하기 위해서 컨트롤러를 설치해줄 필요가 있다.AWS의 경우 AWS Load Balancer Controller를 설치해주어야한다. AWS Load Balancer Controller (LBC)Kubernetes 클러스터 내의 LoadBalancer와 Ingress 서비스를 각각 AWS NLB, ALB로 연결해주는 Controller 이 LBC는 클러스터 ..

앞서 리소스 스케쥴링 중 Taint와 Tolerant, 그리고 node Affinity를 잠깐 알아보았다.이번에는 리소스 스케쥴링 전략 중 Affinity를 알아보도록 한다. AffinityPod가 특정 node에 배치되도록 설정하는 정책, Pod에 적용되는 설정앞서 살펴본 Taint는 Pod가 특정 node에 배치되지 않도록 하는 정책으로, node에 적용하는 설정이였다. Affinity에는 node를 기준으로 하는 node Affinity와 pod를 기준으로 하는 pod Affinity가 있다.각 Affinity는 조건의 강도에 따라 2종류로 나뉘게 된다.requiredDuringSchedulingIgnoredDuringExecution : 이 조건을 만족하는 node에만 pod를 스케쥴링 (Hard..