search

smart-devops-org / devops-system

devops 시스템 설정
0 stars 0 forks source link

readme

EKS 공부 + kubernetes object 정리 + devops tool + CI/CD 사용 프로젝트

개요

목적

  1. vpc, subnet ,보안 그룹, eks, node-group, 로드밸런서, route53, auto-scale ,EBS,ECR ,IAM 등 eks로 운영환경 구축시 필요간 기본적인 세팅을 혼자 할 수 있도록 한다(AWS 리소스 파악 정리)
  2. kubernetes 사용 필요한 object에 대한 기초를 확실히 한다
  3. devops 운영시 필요한 tools에 대한 이해 및 정리 한다
  4. github Action or jenkins , ArgoCD를 활용한 CI/CD 환경을 구축한다

의의

| 해당 프로젝트를 통해 기초적인 부분으로 어떻게 devops 기본 능력치 확인,정리 및 이직 준비할 때의 자료로 사용한다

1. AWS 리소스 파악 정리

1.1 VPC 란

image

1.2 VPC 기본 구성

서브넷

IP 대역

- 10.0.0.0 ~ 10.255.255.255(10/8 prefix)

- 172.16.0.0 ~ 172.31.255.255(182.16/12 prefix)

- 192.168.0.0 ~ 192.168.255.255(192.168/16 prefix)

라우터

라우팅 테이블

image

게이트웨이 및 엔드 포인트

image image

보안 그룹

NACL

image

참고 링크

1.3 EKS

image

1.4 EKS 특징

VPC(Virtual Private Cloud) 와 통합

cf) 심리스(Seamless): 서비스 접근을 단순하게 하는 것 혹은 복잡한 기술이나 기능을 설명하지 않아도 서비스 기능을 직관적으로 구현하는 뜻

image

ELB와의 연계

IAM 을 통한 인증과 인가

워커 노드

image

EC2 Fargate
관리 부하 높음 낮음
제약 적음 많음
특징 관리형 노드 그룹으로 EC2에 통합된 워커노드로 동작 워커 노드도 완전히 AWS가 관리하며 사용자는 EC2를 관리하지 않아도 됨

AWS side workflow

image

  1. 쿠버네티스의 api 서버를 각 가용영역에 배포
  2. api 데이터, 쿠버네티스의 상태 데이터를 확인하기 위해 etcd를 같이 배포
  3. 쿠버네티스에서 오는 call 에 대한 IAM 구성
  4. 쿠버네티스 마스터 노드의 오토스케일링 설정
  5. 클러스터가 안정적으로 구현하도록 여기에 연결할 수 있는 로드밸런서를 구성

image

참고 링크

1.5 nodegroup (관리형 노드 그룹)

참고 링크

1.6 로드 밸런서

image

ELB 의 기본 구성

리스너는 외부의 요쳥을 받아들이기 때문에 서비스 포트를 보유하고 있으며 외부의 요청은 서비스 포트로 접속하는 요청만을 처리

대상 그룹 또한 서비스 포트를 보유하고 있으며 부하분산 대상인 EC2는 해당 포트가 열려 있어야 함(NodePort) 사용 L4 스위치와 비교해보면 리스너는 Virtual Server에 , 대상 그룹은 Pool에 해당함

image

image

참고 링크

1.7 ELB의 종류

Application Load Balancer(ALB)

- OSI 7계층의 해당하는 로드밸런서
- HTTP, HTTPS의 특성을 주로 다루는 로드밸런서
- 단순 부하분산 뿐만 아니라 http의 헤더 정보를 이용해 부하분산을 가능
  - ec2 -> 로드밸런서 -> 리스너 -> 규칙 -> ALB 규칙 보기/편집
- HTTP의 헤더의 값을 보고 이 요청은 어느 대상 그룹으로 보낼지 판단 가능
  - ec2 -> 로드밸런서 -> 리스너 -> 규칙 -> ALB 규칙 보기/편집 -> 조건 추가
- 부하분산 방식 설정 가능
  - ec2 -> 로드밸런서 -> 대상 그룹 - 그룹 상세 - 속성 - 로드 밸런싱 알고리즘
- 인증서를 탑재할 수 있어 대상 그룹의 EC2를 대신하여 SSL 암호와/ 복호화를 대신 진행 가능(ACM 사용)
- 로드밸런서는 요청을 받으면 우선순위에 따라 리스너 규칙을 평가하여 적용할 규칙을 결정한 다음, 규칙 작업의 대상 그룹에서대상을 선택
- 프록시 서버로서의 역할
- AWS Web Aplication Firewal 과 연동(방화벽 서비스와 연동 가능)

image

image

image

image

image

image

Network Load Balancer(NLB)

image

image

참고 링크

1.8 Route 53

NS 타입

SOA 타입

A 타입

CNAME

image

image

참고 링크

1.9 Auto-scale

image

참고 링크

1.10 IAM

image

IAM 작동 방식

보안주체 -> 요청 -> 인증 -> 인가 -> 작업 또는 연산 -> 리소스

종류 설명
보안 주체 AWS 리소스에 대한 조치 또는 작업을 수행하도록 요청하는 AWS의 엔티티(사용자,서비스 또는 역할) 주체는 보안 자격 증명을 사용하거나 임시 보안 자격 증명으로 IAM 역할을 가정하여 인증
요청 사용자, 서비스 또는 애플리케이션이 AWS 리소스에 대한 조치 또는 작업을 수행하도록 요청, 요청자는 보안 자격증명을 사용하거나 임스 보안 자격 증명으로 IAM 역할을 가정하여 인증된다
인증 IAM은 보안 주체와 연결된 권한을 확인 이러한 권한은 사용자, 그룹 또는 역할에 연결된 IAM 정책에 의해 정의 정첵은 어떤 조건에서 어떤 리소스에 대해 어떤 작업이 허용되거나 거부되는지 지정하는 JSON 문서
인가 보안 주체와 연결된 권한을 정의하는 정책을 기반으로 함, 정책은 사용자, 그룹 또는 역할에 연결할 수 있음, 보안 주체가 AWS 리소스에 대한 작업을 수행하도록 요청하면 IAM은 연결된 정책을 평가하여 요청이 허용되는지 또는 거부 되는지 결정
작업 연산 요청 엔티티가 평가된 정책을 기반으로 요청된 작업 또는 연산을 수행할 권한이 있는 경우 IAM은 요청을 진행하도록 허용, 그렇지 않으면 IAM이 요청을 거부하고 작업이 수행되지 않음
리소스 요청이 IAM에 의해 승인된 경우 지정된 AWS 리소스에서 작업이 수행된다

IAM 구성

  1. 사용자
  1. 그룹
  1. 정책
  1. 역할

IAM 자격 증명 공급자 유형 OIDC()

image

참고 링크

1.11 EBS 란?

EBS 기능

참고 링크

1. 12 ECR 이란?

ECR 기능

참고 링크

2 kubernetes 기본 Object 정리

2.1 Workload

Cluster

마스터 노드(컨트롤 플레인) 워커 노드
컨테이너를 통제하는 역할, 대규모의 컨테이너를 운영하려면 각 워커 노드들의 가용 리소스 현황을 고려하여 최적의 컨테이너 배치와 모니터링 그리고 각 컨테이너에 대한 효율적인 추적 관리를 수행 다른 컨테이너들이 선적된 컨테이너 선의 역할, 각기 다른 목적과 기능으로 세분화된 컨테이너들이 실제 배치되는 노드를 의미

image

image

node

taints && toleration

image

참고 자료

Nodes

워크로드 resource를 사용하여 파드의 라이프사이클을 관리

Deployments && ReplicaSet

image

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: test-replicaset
spec:
  template:
    metadata:
      name: test-replicaset
      labels:
        app: test-replicaset
    spec:
      containers:
      - name: test-replicaset
        image: nginx
        ports:
        - containerPort: 80
  replicas: 3
  selector:
    matchLabels:
      app: test-replicaset
- apiVersion apps/v1 → 쿠버네티스의 apps/v1 API를 사용
- kind: ReplicaSet → ReplicaSet의 작업으로 명시
- metadata.name → Replicaset 이름을 설정
- spec.template.metadata → 어떤 파드를 실행할지에 대한 정보를 하위에 설정 
- spec.template.metadata.name → 생성될 파드의 이름을 지정
- spec.template.metadata.labels.app:test-replicaset → 식별하는 레이블이 앱 컨테이너이며 test-replicaset 으로 식별
- spec.spec → 이 하위의 옵션들은 컨테이너에 대한 설정을 합니다. 위 코드에선 컨테이너 명, 이미지, 포트를 지정 했다.
- replicas → 파드의 개수를 몇개 유지할 것 인지 설정, 기본값은 1 
- selector → 어떤 레이블의 파드를 선택하여 관리할지에 대한 설정. 앱 컨테이너의 test-replicaset 레이블을 식별하여 해당되는 파드들을 관리하며, 이 필드가 없을 경우 spec.template.metadata.labels.app 에 적은 내용들을 기본값으로 사용

StatefulSets

DaemonSet

image

Jobs/CronJob

2.2 서비스

port : 서비스 쪽에서 해당 파드를 향해 열려있는 포트를 의미한다.

ClusterIP

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  type: ClusterIP
  ports:
  - name: http
    protocol: TCP
    targetPort: 9376
    port: 80
  - name: https
    protocol: TCP
    targetPort: 9377
    port: 443
  selector:
    app: myapp
    type: frontend

image

NodePort

image

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  type: NodePort
  ports:
  - targetPort: 80      # 애플리케이션(파드)을 노출하는 포트
    port: 80            # 서비스를 노출하는 포트
    nodePort: 30008     # 외부 사용자가 애플리케이션에 접근하기 위한 포트번호(선택)
  selector:             # 이 서비스가 적용될 파드 정보를 지정
    app: myapp
    type: frontend

LoadBalancer

image

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  type: LoadBalancer
  ports:
    - protocol: TCP
      port: 80              # 서비스를 노출하는 포트
      targetPort: 80        # 애플리케이션(파드)를 노출하는 포트
  clusterIP: 10.0.171.239   # 클러스터 IP
  selector:
    app: myapp
    type: frontend
status:
  loadBalancer:             # 프로비저닝된 로드 밸런서 정보
    ingress:
    - ip: 192.0.2.127

ExternalName

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
  namespace: prod
spec:
  type: ExternalName
  externalName: my.database.example.com

Ingress

image

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx-example
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80

참고 링크

2.3 Storage

image

image

pv pvc storageclass
스토리지 볼륨 정의 pv를 요청 디스크 생성시 디스크 타입을 정의하도록 동적 프로비저닝 방식을 이용

image

참고 링크

2.4 config

ConfigMap

Secret이란

image

ConfigMap, Secret의 3가지 사용방법

  1. 상수를 환경변수로 사용 image

  2. 파일을 환경변수로 사용 image

  3. Pod내부의 파일로 마운트해 사용 image

2.5 네임스페이스

namespace

클러스터 기본 namespace

default kube-system kube-public kube-node-lease
Namespace를 지정하지 않은 경우에 기본적으로 할당되는 Namespace이다 쿠버네티스 시스템에 의해 생성되는 API 오브젝트들을 관리하기 위한 Namespace이다. 클러스터 내 모든 사용자로부터 접근 가능하고 읽을 수 있는 오브젝트들을 관리하기 위한 Namespace이다. 쿠버네티스 클러스터 내 노드의 연결 정보를 관리하기 위한 Namespace이다.
지금까지 사용해왔던 방식이다. (지금까지 Namespace를 지정했던 적은 없었다.) 클러스터 레벨의 관리자 영역의 Namespace라고 이해하면 좋다. 사용자가 직접 다루지는 않지만 누구든 접근 가능하기 때문에 주의할 필요는 있다. 역시 사용자가 직접 다루기보단, 쿠버네티스 자체적으로 컨트롤플레인과 노드간의 연결을 잘 하기 위해서 lease라는 오브젝트를 관리하게 되는데 => 즉 lease를 잘 관리하기 위한 Namespace이다.

image

ResourceQuota

apiVersion: v1
kind: ResourceQuota
metadata:
  name: rq-1
  namespace: nm-3
spec:
  hard:
    requests.memory: 1Gi
    limits.memory: 1Gi

image

image

LimitRange

apiVersion: v1
kind: LimitRange
metadata:
  name: lr-1
spec:
  limits:
  - type: Container
    min:
      memory: 0.1Gi
    max:
      memory: 0.4Gi
    maxLimitRequestRatio:
      memory: 3
    defaultRequest:
      memory: 0.1Gi
    default:
      memory: 0.2Gi

image

2.6 Access Control

image

인증

# 어떤 인증 방법을 사용하는지 확인 가능
k -v=7 get no
apiVersion: v1
kind: ServiceAccount
metadata:
  name: test-a
  namespace: default
secrets:
  - name: secret-sa-test-a
apiVersion: v1
kind: Secret
metadata:
  name: secret-sa-test-a
  namespace: default
  annotations:
    kubernetes.io/service-account.name: "test-a"
type: kubernetes.io/service-account-token

curl -k -X GET -H "Authorization: Bearer 토큰" https://3929D75683562F7DFBE99C3BBA94C090.gr7.ap-northeast-2.eks.amazonaws.com/api/v1/namespace/default/pods

image

어플리케이션 운영의 인증 관리

위와 같은 부분으로 각 권한에 맞는 그룹 developer, devops, sqa 등으로 service account를 만들고 각 그룹에 맞는 권한을 세팅해 주는 식으로 사용 가능

Role & RoleBinding을 이용한 권한 제어

image

3. devops tools 정리

3.1 CI/CD

3.2 Servicemesh

3.3 Monitoring

3.4 Logging

3.5 Database

3.6 Workflow

3.7 MessageBus

3.8 Auth