우드의개발개발

1. Kubernetes API 쿠버네티스 API는 목적에 따라 그룹화 되어 있다. version은 쿠버네티스의 버전을 보여주는 기능을 담당한다. metrics와 healthz는 클러스터의 상태를 모니터하는데 기능을 담당한다. logs는 써드파티 앱과 쓰여 로그와 관련된 기능을 담당한다. api와 apis에 대해 조금더 자세히 살펴보자.  api는 코어그룹이라고해서 위 그림에서 보시다 시피 쿠버네티스의 기본적인 리소스를 포함한다. 경로에 그룹 이름이 따로 붙지 않아 /api/v1/pods 와 같은 방식으로 접근한다. curl 명령어를 통해 kube-apiserver를 조회해서 조회할 수 있는 api목록을 확인할 수 있다.. apis는 Non-Core API Grouops이라고 해서 Core API 외에 ..

1. 쿠버네티스 클러스터 접근 주체쿠버네티스 클러스터에 접근하는 주체에는 관리자, 개발자 그리고 서비스 어카운트가 있다. 쿠버네티스는 파일, 인증서 그리고 LDAP 같은 수단을 통해 접근 주체의 인증을 처리하고 있다. 쿠버네티스 클러스터의 대표적인 컴포넌트인 kube-apiserver에 접근하는 방법으로 kubectl을 이용한 방법과 curl을 이용한 방법이 있다. 이 때 클러스터는 유저의 인증 및 요청을 처리한다. 클러스터는 4가지 유형으로 유저의 인증을 처리한다. 1.1 유저 인증 처리 방법 - 유저 아이디 + 패스워드- 토큰- 인증서- 외부 인증 서비스 1.1.1 유저 아이디 + 패스워드 / 토큰.csv 파일을 만들어 해당 파일 안에 패스워드, 유저 이름, 유저 아이디, 그룹을 명시한다. 이후 서비..

YAML FILE이 YAML 파일은 GitLab CI/CD 파이프라인 구성을 보여주고 있습니다. 이를 통해 코드가 특정 브랜치로 커밋될 때 테스트와 배포 작업을 자동으로 처리할 수 있습니다.1. Pipeline파이프라인이란 작업들을 논리적으로 묶어서 실행하는 단위를 말합니다. 이 예시에서는 `My Awesome App Pipeline`이라는 이름을 가진 파이프라인이 정의되어 있습니다. rules조건에 따라 파이프라인 실행 여부를 결정합니다. 여기서는 `main` 브랜치로 커밋이 발생했을 때 파이프라인이 실행되도록 설정되어 있습니다.2. Stages파이프라인은 여러 단계(stages)로 나눌 수 있습니다. 각 단계는 연속적으로 실행됩니다. 여기서 test와 deploy라는 두 가지 단계가 정의되어 있습니다..

CI (Continuous Integration) 개발자가 피처 브런치를 생성해서 작성한 코드를 PR하여 동료들의 리뷰를 받은 후 위 주황색 단계를 거쳐 승인이 난 후에 메인 브런치에 코드가 머지됩니다. 주황색 단계에는 단위 테스트, 의존성 검사, 소스 코드 빌드, 실행 파일 검사 단계를 포함합니다. CD (Continuous Deployment/ Delivery ) 위 시나리오에서 CD는 CI 과정 이후 운영 서버로 배포하기 전 테스트 서버로 실제 배포를 한 뒤 이상이 없을 경우 메인 브런치로 코드를 머지 후 CI와 CD과정을 거쳐 운영 서버에 배포합니다. 개념적으로 CD는 실제 서버에 코드를 배포하는 것입니다. 위 과정에서 CI CD는 개발자가 PR을 통해 올린 코드가 배포까지 빠르게 이루어지는 과정..

1. Virtualbox 설치 (7.0.8 버전)https://download.virtualbox.org/virtualbox/7.0.8/VirtualBox-7.0.8-156879-Win.exe  2. Vagrant 설치 (2.3.4 버전)https://releases.hashicorp.com/vagrant/2.3.4/vagrant_2.3.4_windows_amd64.msi ​3. Vagrant 스크립트 실행# Vagrant 폴더 생성C:\Users\사용자> mkdir k8s && cd k8s# Vagrant 스크립트 다운로드curl -O https://raw.githubusercontent.com/k8s-1pro/install/main/ground/k8s-1.27/vagrant-2.3.4/Vagrantf..

Kubernetes에서 파드가 배포되는 과정은 스케줄러에 의해 관리되며, 파드를 클러스터 내의 적합한 노드에 배치하는 절차입니다. 이 과정은 네 단계(Scheduling Procedure)로 나뉘고, 각 단계는 특정 플러그인(Plugins for each Stage)을 통해 처리됩니다. 1. Scheduling Queue (스케줄링 큐)파드를 생성하면, 해당 파드는 먼저 스케줄링 큐에 들어갑니다. 이 큐는 아직 할당되지 않은 파드들의 대기열 역할을 하며, 파드가 실행 가능한 상태가 될 때까지 유지됩니다.관련 플러그인:PrioritySort: 파드의 우선순위를 기준으로 큐에서 대기 중인 파드를 정렬합니다. 우선순위가 높은 파드가 먼저 처리되도록 보장합니다.2. Filtering (필터링)스케줄러는 큐에서 ..

스태틱 파드와 데몬셋 비교

테인트와 톨러레이션테인트는 노드에 적용되고, 톨러레이션은 파드에 적용됩니다. 톨러레이션의 옵션에는 세 가지가 있습니다: NoSchedule, PreferNoSchedule, NoExecute입니다.1. NoSchedule: 이 옵션이 설정된 노드에는 특정 조건을 만족하지 않는 파드가 스케줄링되지 않습니다. 즉, 노드에 설정된 테인트와 일치하지 않는 파드는 해당 노드에 배치될 수 없습니다.  2. PreferNoSchedule: 이 옵션은 노드가 파드를 가능한 한 스케줄링하지 않도록 선호하지만, 필수는 아닙니다. 즉, 특정 조건을 만족하지 않더라도 파드는 해당 노드에 스케줄링될 수 있습니다.3. NoExecute: 이 옵션은 노드에서 실행 중인 파드가 특정 조건을 만족하지 않을 경우, 해당 파드를 강제로 ..

1.  감사 정책 파일 생성로그로 기록하고 싶은 감사 정책 파일을 작성해야합니다. 이 때 파일 내 group 부문에 무엇을 적어야 할지에 대해 잠시 알아보겠습니다. group에는 공식문서 Kubernetes v1.20 [stable] 기준 4가지 그룹이 있습니다. 아래와 같으니 리소스 명시하실 때 그룹을 잘 지정해서 명시하시길 바랍니다. core- pods, services, configmaps, sercrets, namespaces, persistentvolumes, persistentvolumeclaims, nodes, namespaces, endpoints apps- deployments, replicasets, statefulsets batch- jobs, cronjobs networking.k8..

ClusterRole + RoleBinding의 조합ClusterRole: 클러스터 전체에서 작동하는 권한을 정의합니다. 특정 네임스페이스가 아닌 클러스터 전체에서 리소스에 접근할 수 있는 권한을 설정할 수 있습니다. RoleBinding: 특정 네임스페이스 내에서 사용자를 ClusterRole과 연결하는 역할을 합니다.특징이 조합을 사용하면 ClusterRole에서 정의된 클러스터 전반에 걸친 권한을, 특정 네임스페이스 내에서만 적용할 수 있습니다. ClusterRole에 "Pod를 읽을 수 있는 권한"이 있다고 해도, RoleBinding을 통해 그 권한을 특정 네임스페이스에만 제한해서 적용할 수 있습니다.Role + ClusterRoleBinding의 조합Role: 특정 네임스페이스 내에서만 작동하..