From bbe0a26311a65af92549109637c42463006da96a Mon Sep 17 00:00:00 2001 From: Zerotay Date: Mon, 30 Dec 2024 18:07:59 +0900 Subject: [PATCH 1/2] [ko] update pod/_index.md for v1.32 --- .gitignore | 3 + .../ko/docs/concepts/workloads/pods/_index.md | 161 ++++++++++-------- 2 files changed, 97 insertions(+), 67 deletions(-) diff --git a/.gitignore b/.gitignore index f4768d7f871be..e1bd69c71f632 100644 --- a/.gitignore +++ b/.gitignore @@ -39,3 +39,6 @@ package-lock.json # Generated files when building with make container-build .config/ .npm/ + +# Obsidian files +.obsidian/ \ No newline at end of file diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md index aa3ca80a64a99..4a8aa207a88e8 100644 --- a/content/ko/docs/concepts/workloads/pods/_index.md +++ b/content/ko/docs/concepts/workloads/pods/_index.md @@ -3,6 +3,9 @@ # - erictune title: 파드 content_type: concept +api_metadata: +- apiVersion: "v1" + kind: "Pod" weight: 10 no_list: true card: @@ -32,18 +35,32 @@ _파드_ (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로) ## 파드란 무엇인가? {{< note >}} -[도커](https://www.docker.com/)가 가장 일반적으로 잘 알려진 -{{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}이지만, -쿠버네티스는 도커 외에도 다양한 컨테이너 런타임을 지원하며, -파드를 설명할 때 도커 관련 용어를 사용하면 더 쉽게 설명할 수 있다. +파드가 실행되기 위해 각 노드에 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)를 설치해야 한다. {{< /note >}} -파드의 공유 콘텍스트는 리눅스 네임스페이스, 컨트롤 그룹(cgroup) 및 +파드의 공유 콘텍스트는 리눅스 네임스페이스, 컨트롤 그룹(cgroup) 및 {{< glossary_tooltip text="컨테이너" term_id="container" >}}를 격리하는 것과 같이 잠재적으로 다른 격리 요소들이다. 파드의 콘텍스트 내에서 개별 애플리케이션은 추가적으로 하위 격리가 적용된다. 파드는 공유 네임스페이스와 공유 파일시스템 볼륨이 있는 컨테이너들의 집합과 비슷하다. +쿠버네티스 클러스터의 파드는 두 가지 주요 방식으로 사용된다. + +* **단일 컨테이너를 실행하는 파드**. "파드 당 하나의 컨테이너" 모델은 + 가장 일반적인 쿠버네티스 유스케이스이다. 이 경우, 파드를 단일 컨테이너를 둘러싼 + 래퍼(wrapper)로 생각할 수 있다. 쿠버네티스는 컨테이너를 직접 관리하는 대신 + 파드를 관리한다. +* **함께 작동해야 하는 여러 컨테이너를 실행하는 파드**. 파드는 + 밀접하게 결합되어 있고 리소스를 공유해야 하는 [함께 배치된 여러 개의 컨테이너](#how-pods-manage-multiple-containers)로 + 구성된 애플리케이션을 캡슐화할 수 있다. 이런 함께 배치된 컨테이너는 단일의 응집된 유닛을 형성한다. + + 단일 파드에서 함께 배치된 또는 함께 관리되는 여러 컨테이너를 그룹화하는 것은 + 비교적 고급 유스케이스이다. 이 패턴은 컨테이너가 밀접하게 결합된 + 특정 인스턴스에서만 사용해야 한다. + + (회복력이나 수용력을 위해) 복제를 하고자 여러 컨테이너를 실행할 필요는 없다. + 여러 복제가 필요하다면, [워크로드 관리](/ko/docs/concepts/workloads/controllers/)를 보도록 한다. + ## 파드의 사용 다음은 `nginx:1.14.2` 이미지를 실행하는 컨테이너로 구성되는 파드의 예시이다. @@ -59,34 +76,13 @@ kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml [파드 작업](#파드-작업) 섹션에서 파드와 워크로드 리소스의 관계에 대한 더 많은 정보를 확인한다. -### Workload resources for managing pods +### 파드 관리를 위한 워크로드 리소스 일반적으로 싱글톤(singleton) 파드를 포함하여 파드를 직접 만들 필요가 없다. 대신, {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}과 같은 워크로드 리소스를 사용하여 생성한다. 파드가 상태를 추적해야 한다면, {{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}} 리소스를 고려한다. -쿠버네티스 클러스터의 파드는 두 가지 주요 방식으로 사용된다. - -* **단일 컨테이너를 실행하는 파드**. "파드 당 하나의 컨테이너" 모델은 - 가장 일반적인 쿠버네티스 유스케이스이다. 이 경우, 파드를 단일 컨테이너를 둘러싼 - 래퍼(wrapper)로 생각할 수 있다. 쿠버네티스는 컨테이너를 직접 관리하는 대신 - 파드를 관리한다. -* **함께 작동해야 하는 여러 컨테이너를 실행하는 파드**. 파드는 - 밀접하게 결합되어 있고 리소스를 공유해야 하는 함께 배치된 여러 개의 컨테이너로 - 구성된 애플리케이션을 캡슐화할 수 있다. 이런 함께 배치된 컨테이너는 - 하나의 결합된 서비스 단위를 형성한다. 예를 들어, 하나의 컨테이너는 공유 볼륨에 - 저장된 데이터를 퍼블릭에 제공하는 반면, 별도의 _사이드카_ 컨테이너는 - 해당 파일을 새로 고치거나 업데이트한다. - 파드는 이러한 컨테이너, 스토리지 리소스, 임시 네트워크 ID를 - 단일 단위로 함께 래핑한다. - - {{< note >}} - 단일 파드에서 함께 배치된 또는 함께 관리되는 여러 컨테이너를 그룹화하는 것은 - 비교적 고급 유스케이스이다. 이 패턴은 컨테이너가 밀접하게 결합된 - 특정 인스턴스에서만 사용해야 한다. - {{< /note >}} - 각 파드는 특정 애플리케이션의 단일 인스턴스를 실행하기 위한 것이다. 더 많은 인스턴스를 실행하여 더 많은 전체 리소스를 제공하기 위해 애플리케이션을 수평적으로 확장하려면, 각 인스턴스에 하나씩, 여러 파드를 사용해야 한다. @@ -98,24 +94,8 @@ term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="jo 자동 복구를 구현하는 방법에 대한 자세한 내용은 [파드와 컨트롤러](#파드와-컨트롤러)를 참고한다. -### 파드가 여러 컨테이너를 관리하는 방법 - -파드는 응집력있는 서비스 단위를 형성하는 여러 협력 프로세스(컨테이너)를 -지원하도록 설계되었다. 파드의 컨테이너는 클러스터의 동일한 물리 또는 가상 머신에서 -자동으로 같은 위치에 배치되고 함께 스케줄된다. 컨테이너는 -리소스와 의존성을 공유하고, 서로 통신하고, 종료 시기와 방법을 -조정할 수 있다. - -예를 들어, 다음 다이어그램에서와 같이 -공유 볼륨의 파일에 대한 웹 서버 역할을 하는 컨테이너와, 원격 소스에서 해당 파일을 업데이트하는 -별도의 "사이드카" 컨테이너가 있을 수 있다. - -{{< figure src="/images/docs/pod.svg" alt="파드 생성 다이어그램" class="diagram-medium" >}} - -일부 파드에는 {{< glossary_tooltip text="앱 컨테이너" term_id="app-container" >}} 뿐만 아니라 {{< glossary_tooltip text="초기화 컨테이너" term_id="init-container" >}}를 갖고 있다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 실행되고 완료된다. +파드는 기본적으로 파드에 속한 컨테이너에 [네트워킹](#파드-네트워킹)과 [스토리지](#pod-storage)라는 두 가지 종류의 공유 리소스를 제공한다. -파드는 기본적으로 파드에 속한 컨테이너에 [네트워킹](#파드-네트워킹)과 [스토리지](#pod-storage)라는 -두 가지 종류의 공유 리소스를 제공한다. ## 파드 작업 @@ -135,6 +115,7 @@ term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="jo 파드 오브젝트에 대한 매니페스트를 만들 때, 지정된 이름이 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인한다. +최상의 호환성을 위해 이름은 [DNS 라벨](/ko/docs/concepts/overview/working-with-objects/names/#dns-label-names)을 엄격하게 따라야 한다. ### 파드 OS @@ -142,15 +123,13 @@ term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="jo 파드를 실행할 때 OS를 표시하려면 `.spec.os.name` 필드를 `windows` 또는 `linux`로 설정해야 한다. 이 두 가지 운영체제는 현재 쿠버네티스에서 지원되는 -유일한 운영체제이다. 앞으로 이 목록이 확장될 수 있다. - -쿠버네티스 v{{< skew currentVersion >}}에서, 이 필드에 대해 설정한 값은 -파드의 {{< glossary_tooltip text="스케줄링" term_id="kube-scheduler" >}}에 영향을 미치지 않는다. -`.spec.os.name`을 설정하면 파드 검증 시 -OS를 식별하는 데 도움이 된다. -kubelet은 -자신이 실행되고 있는 노드의 운영체제와 -동일하지 않은 파드 OS가 명시된 파드의 실행을 거부한다. +유일한 운영체제이다. 앞으로 이 목록은 확장될 수 있다. + +쿠버네티스 v{{< skew currentVersion >}}에서, `spec.os.name`은 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}가 어떤 노드에 파드를 스케줄할지 영향을 주지 않는다. +하나 이상의 운영 체제를 운영하는 모든 클러스터에서는 +[kubernetes.io/os](/docs/reference/labels-annotations-taints/#kubernetes-io-os) + 라벨을 각 노드에 설정하고, 운영체제 라벨에 맞게 `nodeSelector`를 파드에 정의해야 한다. +kube-scheduler는 다른 기준에 맞춰 파드를 노드에 배정하며, 파드의 컨테이너에 적합한 운영 체제가 위치한 노드를 고르는 것을 실패할 수도 있다. [파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards/)도 이 필드를 사용하여 해당 운영체제와 관련이 없는 정책을 시행하지 않도록 한다. ### 파드와 컨트롤러 @@ -181,6 +160,8 @@ _파드 템플릿_ 에서 파드를 생성하고 사용자 대신 해당 파드 사용하여 실제 파드를 생성한다. `PodTemplate` 은 앱을 실행하는 데 사용되는 워크로드 리소스가 무엇이든지 원하는 상태의 일부이다. +파드를 만들 때, 파드 속 컨테이너를 위한 [환경 변수](/ko/docs/tasks/inject-data-application/define-environment-variable-container/)를 파드 템플릿에 포함시킬 수 있다. + 아래 샘플은 하나의 컨테이너를 시작하는 `template` 이 있는 간단한 잡의 매니페스트이다. 해당 파드의 컨테이너는 메시지를 출력한 다음 일시 중지한다. @@ -258,7 +239,7 @@ spec: 파드는 공유 스토리지 {{< glossary_tooltip text="볼륨" term_id="volume" >}}의 집합을 지정할 수 있다. 파드의 모든 컨테이너는 -공유 볼륨에 접근할 수 있으므로, 해당 컨테이너가 데이터를 공유할 수 +공유 볼륨에 접근할 수 있으므로, 해당 컨테이너들은 데이터를 공유할 수 있다. 또한 볼륨은 내부 컨테이너 중 하나를 다시 시작해야 하는 경우 파드의 영구 데이터를 유지하도록 허용한다. 쿠버네티스가 공유 스토리지를 구현하고 파드에서 사용할 수 있도록 하는 방법에 대한 @@ -271,28 +252,36 @@ spec: 여기에는 IP 주소와 네트워크 포트가 포함된다. 파드 내부(이 경우에 **만** 해당)에서, 파드에 속한 컨테이너는 `localhost` 를 사용하여 서로 통신할 수 있다. -파드의 컨테이너가 *파드 외부의* 엔티티와 통신할 때, +파드의 컨테이너가 *파드 외부의* 엔티티와 통신할 때, 공유 네트워크 리소스(포트와 같은)를 사용하는 방법을 조정해야 한다. 파드 내에서 컨테이너는 IP 주소와 포트 공간을 공유하며, `localhost` 를 통해 서로를 찾을 수 있다. 파드의 컨테이너는 SystemV 세마포어 또는 POSIX 공유 메모리와 같은 -표준 프로세스 간 통신을 사용하여 서로 통신할 수도 있다. +표준 프로세스 간 통신(inter-process communication)을 사용하여 서로 통신할 수도 있다. 다른 파드의 컨테이너는 고유한 IP 주소를 가지며 특별한 구성 없이 OS 수준의 IPC로 통신할 수 없다. 다른 파드에서 실행되는 컨테이너와 상호 작용하려는 컨테이너는 IP 네트워킹을 사용하여 통신할 수 있다. -파드 내의 컨테이너는 시스템 호스트명이 파드에 대해 구성된 +파드 내의 컨테이너는 시스템 호스트명을 파드에 대해 구성된 `name` 과 동일한 것으로 간주한다. [네트워킹](/ko/docs/concepts/cluster-administration/networking/) 섹션에 이에 대한 자세한 내용이 있다. -## 컨테이너에 대한 특권 모드 +## 파드 보안 설정 {#pod-security} -리눅스에서, 파드의 모든 컨테이너는 컨테이너 명세의 [보안 컨텍스트](/docs/tasks/configure-pod-container/security-context/)에 있는 `privileged` (리눅스) 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다. +파드와 컨테이너에 보안 제약을 설정하기 위해서는 파드 명세에 `securityContext` 필드를 사용한다. 이 필드를 통해 파드나 개별 컨테이너가 할 수 있는 행동을 세부적으로 제어할 수 있다. 예를 들어, -클러스터가 `WindowsHostProcessContainers` 기능을 활성화하였다면, 파드 스펙의 보안 컨텍스트의 `windowsOptions.hostProcess` 에 의해 [윈도우 HostProcess 파드](/docs/tasks/configure-pod-container/create-hostprocess-pod)를 생성할 수 있다. 이러한 모든 컨테이너는 윈도우 HostProcess 컨테이너로 실행해야 한다. HostProcess 파드는 직접적으로 호스트에서 실행하는 것으로, 리눅스 특권있는 컨테이너에서 수행되는 관리 태스크 수행에도 사용할 수 있다. 파드의 모든 컨테이너는 윈도우 HostProcess 컨테이너로 반드시 실행해야 한다. HostProcess 파드는 호스트에서 직접 실행되며 리눅스 특권있는 컨테이너에서 수행되는 것과 같은 관리 작업을 수행하는데도 사용할 수 있다. +- CVE 영향을 피하기 위해 특정한 리눅스 기능을 없앤다. +- 파드 내 모든 프로세스가 루트가 아닌(non-root) 유저나 특정 유저, 그룹 ID로 실행되도록 강제한다. +- 특정한 seccomp 프로필을 설정한다. +- 컨테이너를 호스트 프로세스(HostProcess)로 실행하게 하는 등의 윈도우 보안 기능을 설정한다. -{{< note >}} -이 설정을 사용하려면 사용자의 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}이 특권이 있는 컨테이너의 개념을 지원해야 한다. -{{< /note >}} +{{< caution >}} +리눅스 컨테이너에서 [특권 모드](/ko/docs/concepts/security/linux-kernel-security-constraints/#privileged-containers)를 활성화하기 위해 파드 보안 컨텍스트(securityContext)를 사용할 수 있다. +특권 모드는 보안 컨텍스트의 많은 보안 설정을 덮어쓴다. +보안 컨텍스트의 다른 필드들을 통해 동등한 권한을 부여할 수 없는 경우가 아니라면 이 설정을 하는 것을 피하는 것이 좋다. 쿠버네티스 1.26 버전 이후부터 파드 명세의 보안 컨텍스트에 `windowsOptions.hostProcess`를 설정하여 윈도우 컨테이너에서도 비슷한 특권 모드를 실행할 수 있다. 자세한 설명은 [윈도우 호스트프로세스 파드 생성](/docs/tasks/configure-pod-container/create-hostprocess-pod/)을 참고한다. +{{< /caution >}} + +- 사용할 수 있는 커널 레벨의 보안 제약을 배우기 위해서, [파드와 컨테이너를 위한 리눅스 커널 보안 제약](/docs/concepts/security/linux-kernel-security-constraints/)을 본다. +- 파드 보안 컨텍스트에 대해 배우기 위해서, [파드나 컨테이너를 위한 보안 컨텍스트 설정하기](/docs/tasks/configure-pod-container/security-context/)를 본다. ## 정적 파드 @@ -300,8 +289,7 @@ _정적 파드_ 는 {{< glossary_tooltip text="API 서버" term_id="kube-apiserv 관찰하는 대신 특정 노드의 kubelet 데몬에 의해 직접 관리된다. 대부분의 파드는 컨트롤 플레인(예를 들어, -{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}})에 의해 관리되고, 정적 파드의 -경우, kubelet이 각 정적 파드를 직접 감독한다(실패하면 다시 시작한다). +{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}})에 의해 관리되는 반면, 각 정적 파드는 kubelet이 직접 감독한다(실패하면 다시 시작한다). 정적 파드는 항상 특정 노드의 {{< glossary_tooltip term_id="kubelet" >}} 하나에 바인딩된다. 정적 파드의 주요 용도는 자체 호스팅 컨트롤 플레인을 실행하는 것이다. 즉, @@ -311,6 +299,7 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버 생성하려고 한다. 즉, 노드에서 실행되는 파드는 API 서버에서 보이지만, 여기에서 제어할 수는 없다는 의미이다. +더 많은 정보를 위해 [스태틱 파드 생성하기](/ko/docs/tasks/configure-pod-container/static-pod/) {{< note >}} 스태틱 파드의 `스펙(spec)`은 다른 API 오브젝트 @@ -319,9 +308,47 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버 {{< glossary_tooltip text="시크릿" term_id="secret" >}}, 등)가 참조할 수 없다. {{< /note >}} +## 여러 컨테이너를 관리하는 파드 {#how-pods-manage-multiple-containers} + +파드는 응집력있는 서비스 단위를 형성하는 여러 협력 프로세스(컨테이너)를 +지원하도록 설계되었다. +파드의 컨테이너는 클러스터의 동일한 물리 또는 가상 머신에서 +자동으로 같은 위치에 배치되고 함께 스케줄된다. 컨테이너는 +리소스와 의존성을 공유하고, 서로 통신하고, 종료 시기와 방법을 +조정할 수 있다. + + +쿠버네티스 클러스터의 파드는 두 가지 주요 방식으로 사용된다. + +* **단일 컨테이너를 실행하는 파드**. "파드 당 하나의 컨테이너" 모델은 + 가장 일반적인 쿠버네티스 유스케이스이다. 이 경우, 파드를 단일 컨테이너를 둘러싼 + 래퍼(wrapper)로 생각할 수 있다. 쿠버네티스는 컨테이너를 직접 관리하는 대신 + 파드를 관리한다. +* **함께 작동해야 하는 여러 컨테이너를 실행하는 파드**. 파드는 + 밀접하게 결합되어 있고 리소스를 공유해야 하는 함께 배치된 여러 개의 컨테이너로 + 구성된 애플리케이션을 캡슐화할 수 있다. 이런 함께 배치된 컨테이너는 단일의 응집된 유닛을 형성한다. + 예를 들어, 한 컨테이너는 외부로 공유 볼륨에 저장된 데이터를 서비스하는 동안, 별도의 {{< glossary_tooltip text="사이드카 컨테이너" term_id="sidecar-container" >}}가 그 파일들을 재생성하거나 갱신할 수 있다. 파드는 이 컨테이너들과, 스토리지 자원과, 임시 네트워크 ID를 한 유닛으로 함께 묶는다. + + +예를 들어, 다음 다이어그램에서와 같이 +공유 볼륨의 파일에 대한 웹 서버 역할을 하는 컨테이너와, 원격 소스에서 해당 파일을 업데이트하는 별도의 [사이드카 컨테이너](/docs/concepts/workloads/pods/sidecar-containers/)가 있을 수 있다. + +{{< figure src="/images/docs/pod.svg" alt="파드 생성 다이어그램" class="diagram-medium" >}} + +일부 파드에는 {{< glossary_tooltip text="앱 컨테이너" term_id="app-container" >}} 뿐만 아니라 {{< glossary_tooltip text="초기화 컨테이너" term_id="init-container" >}}를 갖고 있다. 기본적으로, 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 실행되고 완료된다. + +또한 메인 애플리케이션 파드에 보조 서비스를 제공하는 [사이드카 컨테이너](/docs/concepts/workloads/pods/sidecar-containers/)를 가질 수도 있다(예: 서비스 메시). + +{{< feature-state for_k8s_version="v1.29" state="beta" >}} + +기본으로 활성화되어있는 `SidecarContainers` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 통해 초기화 컨테이너에 `restartPolicy: Always`를 설정할 수 있다. +재시작 정책 `Always`가 설정된 컨테이너들은 _사이드카_ 로 여겨지며 파드의 전체 라이프타임에 걸쳐 실행되는 것이 보장된다. +사이드카 컨테이너로 명시적으로 정의한 컨테이너는 메인 어플리케이션 파드보다 먼저 실행되며, 파드가 종료될 때까지 실행된다. + + ## 컨테이너 프로브 -_프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는 진단이다. 진단을 수행하기 위하여 kubelet은 다음과 같은 작업을 호출할 수 있다. +_프로브_ 는 컨테이너의 kubelet에 의해 주기적으로 실행되는 진단이다. 진단을 수행하기 위하여 kubelet은 다음과 같은 작업을 호출할 수 있다. - `ExecAction` (컨테이너 런타임의 도움을 받아 수행) - `TCPSocketAction` (kubelet에 의해 직접 검사) @@ -346,6 +373,6 @@ _프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는 * [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema) * [Borg](https://research.google.com/pubs/pub43438.html) -* [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html) +* [Marathon](https://github.com/d2iq-archive/marathon) * [Omega](https://research.google/pubs/pub41684/) * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/). From b18a05c874ef270a4378ef21803b89c0c4206f1c Mon Sep 17 00:00:00 2001 From: Zerotay Date: Tue, 7 Jan 2025 13:49:29 +0900 Subject: [PATCH 2/2] chore: restore .gitignore file --- .gitignore | 3 --- 1 file changed, 3 deletions(-) diff --git a/.gitignore b/.gitignore index e1bd69c71f632..f4768d7f871be 100644 --- a/.gitignore +++ b/.gitignore @@ -39,6 +39,3 @@ package-lock.json # Generated files when building with make container-build .config/ .npm/ - -# Obsidian files -.obsidian/ \ No newline at end of file