Kubernetes 객체 구성

이 주제에서는 Git에서 구성 동기화(Config Sync) 파일을 읽고 이를 클러스터에 자동으로 적용하는 구성을 만드는 방법에 대해 보여줍니다.

시작하기 전에

  • 구성을 YAML과 JSON 등 두 가지 형식 중 하나로 작성해야 하므로 기본적으로 이러한 구문을 이해하고 있어야 합니다. 이 문서에 있는 모든 예시는 사용자가 쉽게 읽을 수 있는 YAML을 사용합니다.

  • 서로 다른 유형의 Kubernetes 객체는 각기 다른 구성을 가지고 있습니다. 이러한 객체 유형의 구성을 만들기 전에 원하는 구성을 수동으로 작성하는 방법을 파악하는 것이 좋습니다.

  • 계층적 저장소를 사용하도록 선택한 경우 계층적 저장소의 구조를 이해해야 합니다. 저장소 내 구성 위치는 구성이 적용되는 클러스터와 네임스페이스에 영향을 줍니다. 이는 namespaces/ 디렉터리의 경우에 특히 그러합니다. namespaces/ 디렉터리의 하위 디렉터리가 추상 네임스페이스 디렉터리에서 구성을 상속할 수 있기 때문입니다.

  • 여기서는 구성 동기화 작동 방식을 설명하기 위해 표준 저장소 예시를 작성했습니다. 여기에는 비구조적 형식계층적 형식, 다중 저장소 모드비다중 저장소 모드, 루트 저장소네임스페이스 저장소를 포함한 여러 예시가 포함됩니다.

    이 주제의 예는 저장소에서 가져온 것이므로 저장소를 브라우저에서 열거나 로컬 시스템에 클론하면 유용할 수 있습니다.

구성 만들기

구성을 만들 때 저장소 내 가장 적합한 위치와 포함할 필드를 결정해야 합니다.

저장소 위치

  • 비구조적 저장소의 경우 구성을 임의로 만들고 리소스의 하위 폴더를 만들 수 있습니다.

  • 계층적 저장소의 경우 저장소에서 구성 위치는 적용되는 클러스터를 결정하는 요소 중 하나입니다.

    • 네임스페이스를 제외한 클러스터 범위의 객체 구성은 저장소의 cluster/ 디렉터리에 저장됩니다.
    • 네임스페이스와 네임스페이스 범위 객체의 구성은 저장소의 namespaces/ 디렉터리에 저장됩니다.
    • 구성 동기화 구성요소의 구성은 저장소의 system/ 디렉터리에 저장됩니다.
    • Config Management Operator 구성은 저장소에 직접 저장되지 않으며 동기화되지 않습니다.

구성 내용

구성은 kubectl과 비슷한 가산적 방식을 사용합니다. 새 객체를 만들 경우 모든 필수 입력란을 포함해야 합니다. 그러나 기존 객체를 업데이트할 때는 업데이트해야 하는 입력란만 제공하면 됩니다.

구성을 적용할 때 유효한 Kubernetes 객체를 얻어야 합니다.

구성 예

다음 구성 예시는 모두 저장소 예시에서 가져온 것이며, 이를 바탕으로 자신의 구성을 작성할 수 있습니다. 이 목록은 완전한 목록이 아닙니다. 구성 동기화를 사용하면 모든 유형의 Kubernetes 객체를 구성할 수 있습니다.

네임스페이스 구성

이 구성은 gamestore이라는 네임스페이스를 만듭니다.

apiVersion: v1
kind: Namespace
metadata:
  name: gamestore

네임스페이스 구성을 만들 때 네임스페이스에 라벨이나 주석을 추가할 수도 있습니다. NamespaceSelector를 사용하는 경우 라벨이 필요합니다.

다음 구성 예시에서는 gamestore라는 네임스페이스가 없거나 관리되지 않는 경우 해당 네임스페이스를 만듭니다. 네임스페이스의 라벨은 app: gamestore이고 주석은 retail: true입니다. 누군가가 직접 객체의 메타데이터를 수정하면 구성 동기화는 구성의 값으로 신속하게 재설정합니다.

apiVersion: v1
kind: Namespace
metadata:
  name: gamestore
  labels:
    app: gamestore
  annotations:
    retail: "true"

네임스페이스 작업에 대한 자세한 내용은 네임스페이스 및 네임스페이스 범위의 객체 구성을 참조하세요.

ClusterRole 구성

다음 구성에서는 클러스터의 모든 namespace 객체를 읽을 수 있는 권한(get, watch, list)을 제공하는 namespace-reader라는 ClusterRole을 만듭니다. ClusterRole 구성은 주로 ClusterRoleBinding 구성과 함께 사용됩니다.

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: namespace-reader
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "watch", "list"]

ClusterRoleBinding 구성

다음 구성에서는 사용자에게 cheryl@example.com namespace-reader ClusterRole 권한을 부여하는 namespace-readers라는 ClusterRoleBinding을 만듭니다.

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: namespace-readers
subjects:
- kind: User
  name: cheryl@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: namespace-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding은 클러스터 범위이며 네임스페이스 디렉터리나 추상 네임스페이스에 배치될 수 없습니다.

PodSecurityPolicy 구성

다음 예시에서는 psp라는 PodSecurityPolicy를 만듭니다. 이 정책은 권한을 사용하는 컨테이너 실행을 허용하지 않지만 노드의 유효한 사용자가 컨테이너를 실행할 수 있게 허용합니다.

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  name: psp
spec:
  privileged: false
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'

PodSecurityPolicy는 클러스터 범위이며 네임스페이스 디렉터리나 추상 네임스페이스에 배치될 수 없습니다.

NetworkPolicy 구성

다음 예시에서는 default-deny-all-traffic이라는 NetworkPolicy를 만듭니다.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny-all-traffic
spec:
  podSelector: {}

NetworkPolicy는 네임스페이스 범위이며 네임스페이스 디렉터리나 추상 네임스페이스에만 배치될 수 있습니다.

위의 NetworkPolicy를 단일 네임스페이스에 적용하면 이 네임스페이스에 있는 모든 pod가 인그레스 트래픽과 이그레스 트래픽에서 분리됩니다.

하위 네임스페이스가 있는 추상 네임스페이스에 동일한 NetworkPolicy를 배치하여 여러 네임스페이스에 적용하면 각 네임스페이스가 NetworkPolicy를 상속합니다. namespace-inheritance 예시 저장소에서 namespaces 디렉터리에는 두 개의 추상 네임스페이스(engrnd)를 포함하며 각 추상 네임스페이스는 두 개의 실제 네임스페이스인 analyticsgamestore, incubator-1incubator-2를 각각 포함합니다. 추상 네임스페이스에 위의 default-deny-all-traffic NetworkPolicy를 추가하면 4개의 실제 네임스페이스가 각각 NetworkPolicy를 상속하므로 각 Pod가 인그레스 트래픽과 이그레스 트래픽으로부터 보호됩니다.

네임스페이스 상속을 사용하면 최소 권한 보안 방식을 적용할 수 있습니다. 예를 들어 이전 NetworkPolicy 예시가 추상 네임스페이스 모두에 적용되고 다음 NetworkPolicy가 eng 추상 네임스페이스에 추가되는 경우 인그레스 트래픽은 app:gamestore 라벨이 있는 하위 요소 네임스페이스의 Pod에만 적용됩니다. analytics, incubator-1, incubator-2 네임스페이스는 이 NetworkPolicy의 영향을 받지 않습니다.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-gamestore-ingress
spec:
  podSelector:
    matchLabels:
      app: gamestore
  ingress:
  - {}

ResourceQuota 구성

다음 예시에서는 pod 1개, 100밀리 CPU, 100MiB 메모리에 엄격한 제한을 설정하는 quota라는 ResourceQuota를 만듭니다.

kind: ResourceQuota
apiVersion: v1
metadata:
  name: quota
spec:
  hard:
    pods: "1"
    cpu: "100m"
    memory: "100Mi"

지정된 유형의 새 객체 생성이 기존의 ResourceQuota를 위반하는 경우, Kubernetes는 ResourceQuota를 위반하지 않을 때까지 객체를 만들 수 없습니다.

RepoSync 구성

이 예시에서는 네임스페이스 저장소로부터 동기화되는 루트 저장소에 RepoSync 객체를 만듭니다. RepoSync 객체 구성에 대한 자세한 내용은 네임스페이스 저장소에서 동기화 구성을 참조하세요.

apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: repo-sync
  namespace: gamestore
spec:
  sourceFormat: unstructured
  git:
    repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    branch: main
    dir: quickstart/multirepo/namespaces/gamestore
    auth: none

구성 동기화는 네임스페이스 저장소로부터 동기화를 위해 네임스페이스 조정자를 만듭니다.

다음 단계