...

• 지원하는 애플리케이션의 유형을 제약하지 않는다.

• 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다.

• 애플리케이션 레벨의 서비스를 제공하지 않는다.

• 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 즉, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.

• K8s는 단순한 오케스트레이션 시스템이 아니다. 사실, K8s는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, K8s는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.

...

• kubelet

  • cluster의 각 노드에서 실행되는 에이전트.
    Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리.

  • Kubelet은 8s를 k8s를 통해 생성되지 않는 컨테이너는 관리하지 않는다.

• kube-proxy

  • kube-proxy는 cluster의 각 노드에서 실행되는 네트워크 프록시로, K8s의 서비스 개념의 구현부

  • kube-proxy는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 cluster 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다.

  • kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다.

• Container runtime

  • 컨테이너 실행을 담당하는 소프트웨어

  •  도커(Docker), containerd, CRI-O 그리고 Kubernetes CRI (컨테이너 런타임 인터페이스)를 구현한 모든 소프트웨어 지원.

...

• DNS

  • K8s에 의해 구동되는 컨테이너는 DNS 검색에서 이 DNS 서버를 자동으로 포함한다

• 웹 UI (대시보드)

• 컨테이너 resource 모니터링

  • 컨테이너 resource 모니터링은 중앙 데이터베이스 내의 컨테이너들에 대한 포괄적인 시계열 매트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.

• cluster-레벨 로깅

  • cluster-레벨 로깅 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 진다.

Understanding Terms(중요)

...

# 네임스페이스에 속하지 속하는않는 리소스
$ kubectl api-resources --namespaced=truefalse
NAME                              SHORTNAMES   APIGROUP                       NAMESPACED   KIND
componentstatuses                 cs                                          false        ComponentStatus
namespaces                        ns                                          false        Namespace
nodes                             no                                          false        Node
persistentvolumes                 pv                                          false        PersistentVolume
mutatingwebhookconfigurations                  admissionregistration.k8s.io   false        MutatingWebhookConfiguration
validatingwebhookconfigurations                admissionregistration.k8s.io   false        ValidatingWebhookConfiguration
customresourcedefinitions         crd,crds     apiextensions.k8s.io           false        CustomResourceDefinition
apiservices                                    apiregistration.k8s.io         false        APIService
tokenreviews                                   authentication.k8s.io          false        TokenReview
selfsubjectaccessreviews                       authorization.k8s.io           false        SelfSubjectAccessReview
selfsubjectrulesreviews                        authorization.k8s.io           false        SelfSubjectRulesReview
subjectaccessreviews                           authorization.k8s.io           false        SubjectAccessReview
certificatesigningrequests        csr          certificates.k8s.io            false        CertificateSigningRequest
ingressclasses                                 networking.k8s.io              false        IngressClass
runtimeclasses                                 node.k8s.io                    false        RuntimeClass
podsecuritypolicies               psp          policy                         false        PodSecurityPolicy
clusterrolebindings                            rbac.authorization.k8s.io      false        ClusterRoleBinding
clusterroles                                   rbac.authorization.k8s.io      false        ClusterRole
priorityclasses                   pc           scheduling.k8s.io              false        PriorityClass
csidrivers                                     storage.k8s.io                 false        CSIDriver
csinodes                                       storage.k8s.io                 false        CSINode
storageclasses                    sc           storage.k8s.io                 false        StorageClass
volumeattachments                              storage.k8s.io                 false        VolumeAttachment

# 네임스페이스에 속하지속하는 않는 리소스
$ kubectl api-resources --namespaced=falsetrue
NAME                        SHORTNAMES   APIGROUP                    NAMESPACED   KIND
bindings                                                             true         Binding
configmaps                  cm                                       true         ConfigMap
endpoints                   ep                                       true         Endpoints
events                      ev                                       true         Event
limitranges                 limits                                   true         LimitRange
persistentvolumeclaims      pvc                                      true         PersistentVolumeClaim
pods                        po                                       true         Pod
podtemplates                                                         true         PodTemplate
replicationcontrollers      rc                                       true         ReplicationController
resourcequotas              quota                                    true         ResourceQuota
secrets                                                              true         Secret
serviceaccounts             sa                                       true         ServiceAccount
services                    svc                                      true         Service
controllerrevisions                      apps                        true         ControllerRevision
daemonsets                  ds           apps                        true         DaemonSet
deployments                 deploy       apps                        true         Deployment
replicasets                 rs           apps                        true         ReplicaSet
statefulsets                sts          apps                        true         StatefulSet
localsubjectaccessreviews                authorization.k8s.io        true         LocalSubjectAccessReview
horizontalpodautoscalers    hpa          autoscaling                 true         HorizontalPodAutoscaler
cronjobs                    cj           batch                       true         CronJob
jobs                                     batch                       true         Job
leases                                   coordination.k8s.io         true         Lease
endpointslices                           discovery.k8s.io            true         EndpointSlice
events                      ev           events.k8s.io               true         Event
ingresses                   ing          extensions                  true         Ingress
ingresses                   ing          networking.k8s.io           true         Ingress
networkpolicies             netpol       networking.k8s.io           true         NetworkPolicy
poddisruptionbudgets        pdb          policy                      true         PodDisruptionBudget
rolebindings                             rbac.authorization.k8s.io   true         RoleBinding
roles                                    rbac.authorization.k8s.io   true         Role

...

...

여러가지 배포 방식을 RC나 RS를 이용해서 구현할 수 있지만, 운영이 복잡해지는 단점이 있다. 그래서 쿠k8s에서는 k8s에서는 일반적으로 RC나 RS를 이용해서 배포하지 않고 Deployment라는 개념을 사용한다.

...

이 볼륨 타입을 구별해보면 크게 임시 디스크, 로컬 디스크 그리고 네트워크 디스크 등으로 분류할 수 있다.
지원되는 모든 Storage type은 여기를 참고한다.

emptyDir

emptyDir은 Pod가 생성될 때 생성되고, Pod가 삭제 될 때 같이 삭제되는 임시 볼륨이다.

...

emptyDir의 물리적으로 노드에서 할당해주는 디스크에 저장이 되는데, (각 환경에 따라 다르다. 노드의 로컬 디스크가 될 수 도 있고, 네트워크 디스크 등이 될 수 도 있다.) emptyDir.medium 필드에 “Memory”라고 지정해주면, emptyDir의 내용은 물리 디스크 대신 메모리에 저장이 된다.

만일 한 Pod 내에 Nginx 컨테이너 + fluentd(로그 수집 에이전트) 컨테이너 + emptyDir 볼륨이 있다면, 이 두 컨테이너는 할당된 emptyDir 볼륨을 공유하여 사용하게 된다.(메모리라 하더라도…)
또한 앞서 언급한 바와 같이, 생명 주기도 Pod에 따른다.

...

hostPath는 노드의 로컬 디스크의 directory path를 Pod에서 마운트해서 사용한다. emptyDir과 달리, 같은 hostPath에 있는 볼륨은 여러 Pod 사이에서 공유되어 사용된다.

또한  Pod가 삭제 되더라도 hostPath에 있는 파일들은 삭제되지 않고 다른 Pod가 같은 hostPath를 마운트하게 되면, 남아 있는 파일을 액세스할 수 있다.

...

gitRepo

이 볼륨은 생성 시에 지정된 git repository의 특정 revision의 내용을 clone을 이용해서 내려 받은 후에 디스크 볼륨을 생성하는 방식이다. 물리적으로는 emptyDir이 생성되고, git repository 내용을 clone으로 다운 받는다.

...

• ClusterIP: Default 설정으로, Service에 클러스터 IP (내부 IP )를 할당한다. K8s 클러스터 내에서는 이 Service에 접근이 가능하지만, 클러스터 외부에서는 외부 IP를 할당 받지 못했기 때문에, 접근이 불가능하다.
  LoadBalancer: 보통의 클라우드 ※ ClusterIP의 IP range는 kube-controller-manager pod의 실행 argument 중 --service-cluster-ip-range에 지정된다.(default: --service-cluster-ip-range=10.96.0.0/12)

• LoadBalancer: 보통의 클라우드 벤더에서 제공하는 설정 방식으로, 외부 IP를 가지고 있는 LoadBalancer를 할당한다. 외부 IP를 가지고 있기  때문에, 클러스터 외부에서 접근이 가능하다.
  단, 외부 서비스를 위해 externalIPs를 지정해주어야 하는데, 이는 k8s에서 관리하지 않는다. 즉, 외부 loadbalancer(HAProxy 등)나 Cloud 환경이라면 Cloud 벤더에서 제공하는 loadbalancer의 IP를 별도 지정해주어야 한다.
  아래의 NodePort를 지정하지 않을 경우 랜덤 할당되며, 기능은 아래 NodePort와 같다.
  즉, LoadBalancer+externalIPs+NodePort로 사용 가능 하다.
  또한, 일부 클라우드 공급자는 loadBalancerIP를 지정할 수 있도록 허용하며, 클라우드 공급자가 이 기능을 지원하지 않는 경우, 설정한 loadbalancerIP 필드는 무시된다.

• NodePort: 클러스터 IP로만 접근이 가능한 것이 아니라, 모든 노드의 IP와 포트를 통해서도 접근이 가능하게 된다.
  예를 들어 아래와 같이 hello-node-svc 라는 Service를 NodePort 타입으로 선언을 하고, nodePort를 30036으로 설정하면, 아래 설정에 따라 클러스터 IP의  80포트로도 접근이 가능하지만, 모든 노드의 30036 포트로도 서비스를 접근할 수 있다.
  80포트로 전달된 패킷은 연결된 pod들에 loadbalancing되어 전달된다.

  

  주의할 점은 위의 80 포트도 cluster IP이기 때문에 Cluster 내에서만 접속이 가능하다.
  즉, 위의 ClusterIP + “각 노드에 port forwarding” 기능이라 생각하면 무리가 없을 것이다.

• ExternalName: ExternalName은 외부 서비스를 k8s 내부에서 호출하고자 할 때 사용할 수 있다.

  K8s cluster 내의 Pod들은 클러스터 IP를 가지고 있기 때문에 - 즉, 외부로 통하는 gateway를 가지고 있지 않다 - 클러스터 IP 대역 밖의 서비스를 호출하고자 하면, NAT 설정 등의 복잡한 설정이 필요하다.

  특히, AWS나 GCP와 같은 클라우드 환경을 사용할 경우 DB나, 또는 클라우드에서 제공되는 매지니드 서비스(RDS, CloudSQL)등을 사용하고자 할 경우에는 k8s 클러스터 밖이기 때문에, 호출이 어려운 경우가 있는데, 이를 쉽게 해결할 수 있는 방법이 ExternalName 타입이다.
  
  이 방식도 다시 두 가지 방식으로 설정할 수 있는데,
  첫 번째는 DNS 방식이고, 두 번째는 IP를 지정하는 방식이다.
  
  DNS 방식은 Service object의 spec에 아래와 같이
   type: ExternalName
 externalName: my.database.example.com

  ExternalName과 함께 직접 지정하면 되고, 이 Service는 들어오는 모든 요청을 “my.database.example.com”으로 forwarding 해준다.

  Image RemovedImage Added

  IP를 지정하는 방식은 ClusterIP로 Service를 하나 생성하고, Endpoints라고 하는 object를 하나 더 생성하여, forwarding될 IP와 port를 지정하고 이를 연결하여 사용한다.
  그림으로 나타내면 다음과 같다.

  Image RemovedImage Added

...

• AKS Application Gateway Ingress Controller is an ingress controller that enables ingress to AKS clusters using the Azure Application Gateway.

• Ambassador API 게이트웨이는 Datawire의 커뮤니티 혹은 상업적 지원을 제공하는 Envoy 기반 인그레스 컨트롤러다.

• AppsCode Inc. 는 가장 널리 사용되는 HAProxy 기반 인그레스 컨트롤러인 Voyager에 대한 지원 및 유지 보수를 제공한다.

• AWS ALB 인그레스 컨트롤러는 AWS Application Load Balancer를 사용하여 인그레스를 활성화한다.

• Contour는 Envoy 기반 인그레스 컨트롤러로 VMware에서 제공하고 지원한다.

• Citrix는 베어메탈과 클라우드 배포를 위해 하드웨어 (MPX), 가상화 (VPX) 및 무료 컨테이너화 (CPX) ADC를 위한 인그레스 컨트롤러를 제공한다.

• F5 Networks는 쿠버네티스를 K8s를 위한 F5 BIG-IP 컨테이너 인그레스 서비스에 대한 지원과 유지 보수를 제공한다.

• Gloo는 solo.io의 엔터프라이즈 지원과 함께 API 게이트웨이 기능을 제공하는 Envoy 기반의 오픈 소스 인그레스 컨트롤러다.

• HAProxy 인그레스는 HAProxy를 위한 고도로 커스터마이징 가능한 커뮤니티 주도형 인그레스 컨트롤러다.

• HAProxy Technologies는 쿠버네티스를 K8s를 위한 HAProxy 인그레스 컨트롤러를 지원하고 유지 보수한다. 공식 문서를 통해 확인할 수 있다.

• Istio는 인그레스 컨트롤러 기반으로 인그레스 트래픽을 제어.

• Kong은 오픈소스 API Gateway이며, 쿠버네티스를 K8s를 위한 Kong 인그레스 컨트롤러에 대한 커뮤니티 또는 상업적 지원과 유지 보수를 제공한다.

• NGINX, Inc.는 쿠버네티스를 K8s를 위한 NGINX 인그레스 컨트롤러에 대한 지원과 유지 보수를 제공한다.

• Skipper는 쿠버네티스 K8s 인그레스와 같은 유스케이스를 포함하는 서비스 구성을 위한 HTTP 라우터와 리버스 프록시는 사용자 정의 프록시를 빌드하기 위한 라이브러리로 설계되었다.

• Traefik은 모든 기능(Let's Encrypt, secrets, http2, 웹 소켓)을 갖춘 인그레스 컨트롤러로, Containous에서 상업적인 지원을 제공한다.

Config Map

애플리케이션을 배포하다 보면, 환경에 따라서 다른 설정 값을 사용하는 경우가 있다. 예를 들어, DB의 IP, API를 호출하기 위한 API KEY/TOKEN, 개발/운영에 따른 debug mode, configuration 파일들이 있는데, 애플리케이션 이미지는 같지만, 이런 환경 변수가 차이가 나는 경우 매번 다른 컨테이너 이미지를 만드는 것은 관리상 불편할 수 밖에 없다.

이러한 환경 변수나 설정 값들을 변수로 관리해서 Pod가 생성될 때 이 값을 넣어주거나 또는 디스크 볼륨으로 마운트가 가능한데, 이러한 기능을 제공하는 것이 바로 ConfigMap과 Secret이다.

Service Account

Role & Cluster Role

...

Secret

보안이 중요한 패스워드나, API 키, 인증서 파일들은 Secret에 저장할 수 있다.
Secret은 안에 저장된 내용을 지키기 위해서 추가적인 보안 기능을 제공한다.
예를 들어, API server나 node의 파일에는 저장되지 않고, 항상 메모리에 저장되어 있기 때문에 상대적으로 접근이 어렵다.

하나의 Secret의 사이즈는 최대 1M까지 지원되는데, 메모리에 지원되는 특성 때문에, Secret을 여러 개 저장하게 되면 API Server나 노드에서 이를 저장하는 kubelet의 메모리 사용량이 늘어나서 Out Of Memory와 같은 이슈를 유발할 수 있기 때문에, 보안적으로 꼭 필요한 정보만 secret에 저장하도록 하는 게 좋다.

대부분 ca.crt 같은 인증서나 token key등을 주로 저장한다.

사용 방법에 있어서는 Secret와 ConfigMap은 기본적으로 거의 유사하다. 기본적으로 Key/Value 형태의 저장 구조를 가지고 있으며, 사용 시 환경 변수를 통해서 Pod에 그 값을 전달하거나, 또는 디스크 볼륨으로 마운트가 가능한데, Secret은 정의하는 방법이 다소 차이가 있다.

예를 들어 “language”라는 키로 “java”라는 값을 저장하고자 할 때, ConfigMap의 경우에는 이를 language:java 식으로 일반 문자열로 저장했지만 Secret의 경우에는 값에 해당하는 부분을 base64 포맷으로 인코딩해야 한다.

즉 java라는 문자열을 base64로 인코딩을 하면, amF2YQo= 가 된다.

문자열(“java”)을 base64포맷으로 인코딩 하려면 맥이나 리눅스에서 다음과 같은 명령을 이용하면 된다.

$ echo java | base64

Authentication(사용자 인증)

흔히 말하는 로그인을 말하며, 로그인한 사용자가 본인이 맞는가?에 방점을 두고 있다.
즉, 사용자가 누구인지 식별하는 것을 의미한다.

User Account

K8s는 자체적으로 사용자 계정을 관리하고 이를 인증(Authenticate)하는 시스템을 가지고 있지 않다. 반드시 별도의 외부 계정 시스템을 사용해야 하며, 계정 시스템 연동을 위해서 OAuth나 Webhook가 같은 계정 연동 방식을 지원한다.

Service Account

클라이언트가 k8s API를 호출하거나, 콘솔이나 기타 클라이언트가 k8s API를 접근하고자 할 때, 이는 실제 사람인 사용자가 아니라 시스템이 된다. 그래서, k8s에서는 이를 일반 사용자와 분리해서 관리하는데, 이를 ServiceAccount라고 한다.

ServiceAccount 생성은 다른 object들 보다 간단하게, name과 그 name이 속할 namespace를 명시하고 적용하면 된다. namespace를 지정하지 않으면, “default” namespace로 할당된다.
또한, ServiceAccount를 생성하면 위에 언급한 Secret도 함께(물론 보안 서명 및 token secret 등과 같이…) 자동 생성된다.

$ vim test_serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-test01
  namespace: default

# SA 생성
$ kubectl apply -f test_serviceaccount.yaml

# SA 확인
$ kubectl get sa
NAME        SECRETS   AGE
default     1         9d
sa-test01   1         4s

# 생성된 secrets 확인
$ kubectl get secrets
NAME                    TYPE                                  DATA   AGE
default-token-xh6jf     kubernetes.io/service-account-token   3      9d
sa-test01-token-qthsp   kubernetes.io/service-account-token   3      11s

# 생성된 secrets내 토큰 확인
$ kubectl describe secret sa-test01-token-qthsp
Name:         sa-test01-token-qthsp
Namespace:    default
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: sa-test01
              kubernetes.io/service-account.uid: f7bf0e99-9bd1-4d8c-96f6-a23c5b11d19f

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1025 bytes
namespace:  7 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IjNqSm8xaXJ0MDZsaGxjdzVndWozY1A5VXBGbTdwX3VDUzBpd0J2a3ItR0EifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InNhLXRlc3QwMS10b2tlbi1xdGhzcCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJzYS10ZXN0MDEiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiJmN2JmMGU5OS05YmQxLTRkOGMtOTZmNi1hMjNjNWIxMWQxOWYiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDpzYS10ZXN0MDEifQ.k-ZdSzlMZc4W0IsQi_n37OaSfSto1QuI12Nyv2Nh8Il9hwtctjl-9JBx9bdax13Fq0KRplh_VVh8oAmG9gaGjgyjnb0mq2EUD1ca-vMP1x2otnJScyx75VcYOIP2TXQJ8zObUgSX7odo_otco2ccrK4YbHD3e_T0uDnCuej4vh0KIBUXeG7uMSpiL9LRo4rBKPHo1VAY9Yg5htRvxhKX2OlVZNfvB37rGhAzu67jfVdW9ubg9e724G1jVPipLsiSJ-oyPtx9zXga0gSz_0VJ3KO13hKXmnVi0GD_5sGychwfM2W2T66-cxDTxGZU07LTIpqtHgUA5AZkuwaGPYcYfg

인증 방식에는 인증서 인증 방식 및 토큰 인증 방식 등을 모두 지원하는데,
편의상 보통은 token 방식으로 k8s API를 호출하여 사용한다.

단, k8s API사용을 위한 사용자 인증을 했다 하더라도, 접근하고자 하는 k8s 리소스에 대해 적절한 권한(get, list, watch, create, delete, patch, update, 등)이 부여되어 있어야 한다.
이에 대해서는 다음 섹션에서 다룬다.

Authorization(권한 인증)

Role & Cluster Role

Role은 적용 범위에 따라 ClusterRole과 일반 Role로 분리 된다.

Role의 경우 특정 namespace내의 리소스에 대한 권한을 정의할 수 있다.

반면 ClusterRole의 경우, Cluster 전체에 걸쳐서 권한을 정의할 수 있다는 차이가 있다.
또한 여러 namespace에 걸쳐 있는 nodes 와 같은 리소스에 대해서 권한을 정의할 수 있다.

아래는 default Role 중 User-facing Role에 관한 내용이며, 더 많은 default Role에 대해서는 여기를 참고한다.

Aggregated ClusterRole

또 하나의 유용한 기능으로 aggregationRule이라는 기능이 있다.

보통 ServiceAccount를 생성한 후 Role을 정의할 때, 각 리소스와 액션(verbs)을 지정해야 하는데, 양이 많을 경우 매우 번거로울 수 있다. 이럴 때는 “이미 정의되어 있는 Role + 직접 정의한 Role”로 합칠 수 있다.
(Telegraf와 같은 3rd party 모니터링 솔루션과의 연동 시 매우 유용하다.)

이를 Aggregated ClusterRole 이라 한다.

Role Binding & Cluster Role Binding

위의 Role이나 ClusterRole이 선언/정의되면 단독으로는 무용하며, 실제 사용자나 ServiceAccount와 binding하여 사용된다.

전체적으로 관계를 그림으로 나타내면 다음과 같다.

...

Child Pages

...