[네이버클라우드] Ncloud Kubernetes Service (NKS) 구성 및 실습 Ver.1.27.9 [2]

pyowikiCloud, KubernetesTagged , , , , ,

[네이버클라우드] NKS 초기 구성 및 세팅 Hands on Lab [2]

관리형 쿠버네티스 서비스 NKS(Microservices with NKS)의 두번쨰 내용으로 IAM 인증 사용자 관리 및 서비스 생성 실습을 진행해 보겠습니다.

[네이버클라우드 매뉴얼]
Ncloud Kubernetes Service 클러스터를 생성할 경우, IAM 사용자에게 클러스터 사용 권한을 추가하려면 kube-system 네임스페이스에 ncp-auth ConfigMap을 등록해야 합니다.

[참고]
ncp-iam-authenticator가 설치되고 kubeconfig가 생성된 상태에서 설정 가능합니다. ncp-iam-authenticator 설치, IAM 인증 kubeconfig 생성을 참조

IAM 사용자를 클러스터에 추가

우선 ncp-auth ConfigMap을 생성하여 IAM 사용자를 클러스터에 추가하고 kubectl 자격 증명을 구성해보겠습니다.

$ cat <<EOF | kubectl --kubeconfig $KUBE_CONFIG apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: ncp-auth
  namespace: kube-system
data:
  mapSubAccounts: |
    - subAccountIdNo: <iam-user-idno>
      username: <username>
      groups:
        - <groups>
EOF
  1. ConfigMap의 IAM 사용자 파라미터는 아래와 같습니다.
    • subaccountIdNo: SubAccount 콘솔에서 확인 가능한 추가할 SubAccount 사용자의 ID
    • username: Kubernetes 내에서 IAM 사용자에게 매핑할 사용자 이름.
    • groups: Kubernetes 내에서 사용자에게 매핑할 그룹 목록. 자세한 Default roles and role bindings를 참조

4. sub account의 서브 계정 세부 정보에서 확인 가능한 ID 및 사용할 username을 입력하고 그룹을 지정하여 신규 configmap을 생성했다면 아래의 명령을 통해 ncp-auth ConfigMap에 ncloud.com/applied-ncp-auth 어노테이션을 통해 적용된 사용자 목록을 확인합니다.

$ kubectl -n kube-system get configmap ncp-auth -o yaml
...
metadata:
  annotations:
     ncloud.com/applied-ncp-auth: '[{"SubAccountIdNo":"<iam-user-idno>","Username":"<username>","Groups":["<groups>"]}]'
...
  1. IAM 사용자 또는 역할을 매핑한 Kubernetes 사용자 또는 그룹이 RoleBinding 또는 ClusterRoleBinding을 사용하여 Kubernetes 역할에 바인딩되어 있는지 확인합니다. 자세한 내용은 Kubernetes 문서의 Using RBAC Authorization를 참조.
  • 모든 네임스페이스의 리소스 보기 권한 – 그룹 이름은 full-access-group 이며, 이를 ncp-auth ConfigMap에서 IAM 사용자의 groups에 매핑해야 합니다.
$ cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: full-access-clusterrole
rules:
- apiGroups:
  - ""
  resources:
  - nodes
  - namespaces
  - pods
  verbs:
  - get
  - list
- apiGroups:
  - apps
  resources:
  - deployments
  - daemonsets
  - statefulsets
  - replicasets
  verbs:
  - get
  - list
- apiGroups:
  - batch
  resources:
  - jobs
  verbs:
  - get
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: full-access-binding
subjects:
- kind: Group
  name: full-access-group
  apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: ClusterRole
 name: full-access-clusterrole
 apiGroup: rbac.authorization.k8s.io
EOF

  • 특정 네임스페이스의 리소스 보기 권한 – 파일에 설정된 네임스페이스는 default이므로 원하는 네임스페이스를 지정하여 수정합니다. 그룹 이름은 restricted-access-group이며, 이를 ncp-auth ConfigMap에서 IAM 사용자의 groups에 매핑해야 합니다.
$ cat <<EOF | kubectl --kubeconfig $KUBE_CONFIG apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: restricted-access-clusterrole
rules:
- apiGroups:
  - ""
  resources:
  - nodes
  - namespaces
  verbs:
  - get
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: restricted-access-clusterrole-binding
subjects:
- kind: Group
  name: restricted-access-group
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: restricted-access-clusterrole
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: restricted-access-role
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
- apiGroups:
  - apps
  resources:
  - deployments
  - daemonsets
  - statefulsets
  - replicasets
  verbs:
  - get
  - list
- apiGroups:
  - batch
  resources:
  - jobs
  verbs:
  - get
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: restricted-access-role-binding
  namespace: default
subjects:
- kind: Group
  name: restricted-access-group
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: restricted-access-role
  apiGroup: rbac.authorization.k8s.io
EOF
  1. SubAccount 그룹에 속해있는 SubAccount 사용자는 ncp-sub-account-group:가 prefix로 추가된 Kubernetes 그룹에 포함되게 됩니다.
  2. full-access 라는 SubAccount 그룹에 속한 사용자 전체에 full-access-clusterrole을 부여하는 예시는 아래와 같습니다.
$ cat <<EOF | kubectl --kubeconfig $KUBE_CONFIG apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: full-access-clusterrole
rules:
- apiGroups:
  - ""
  resources:
  - nodes
  - namespaces
  - pods
  verbs:
  - get
  - list
- apiGroups:
  - apps
  resources:
  - deployments
  - daemonsets
  - statefulsets
  - replicasets
  verbs:
  - get
  - list
- apiGroups:
  - batch
  resources:
  - jobs
  verbs:
  - get
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: full-access-binding
subjects:
- kind: Group
  name: ncp-sub-account-group:full-access
  apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: ClusterRole
 name: full-access-clusterrole
 apiGroup: rbac.authorization.k8s.io
EOF

이후 /root/.ncloud/configure에 저장된 설정값을 변경하여 정상적으로 클러스터의 권한이 할당되었는지 확인합니다.

Service 및 Ingress

위 그림과 같이 NKS에서Nodeport 서비스를 구성하여 ALB Ingress Controller 설정을 통해 서비스 트래픽을 라우팅할 수 있습니다.

[ALB Ingress Controller 기본 설정]
-Service type : NodePort (Ingress를 통해 노출시킬 Service는 모두 NodePort type으로 생성)
-Default Rule (Default Rule은 매칭되는 Rule이 없을 때 적용되며 spec.defaultBackend로 설정할 수 있음, 별도의 rule 및 use-annotation 설정은 불가능하며 설정하지 않았을 경우 80 포트로 설정된 기본 타깃 그룹이 생성)
-Rule Priority (Ingress에서 정의한 Rule의 순서에 따라 우선 순위가 결정됨, 가장 위에 있는 Rule의 우선 순위가 1)

아래 주의사항과 같이 LB는 리소스 레벨에서 수정해야 하며, 콘솔 및 API를 활용하여 제어하는 경우 동기화 문제가 발생할수 있습니다.

1편에서 소개한 NKS 클러스터 초기 설정을 위해 선택한 하이버 바이저인 KVM의 경우 클러스터는 ALB Ingress Controller를 기본으로 포함하고 있기 때문에 별도 설치 없이 바로 사용할 수 있습니다.

ALB Ingress Controller 설정 및 어노테이션 및 하이퍼바이저 XEN을 선택한 클러스터의 경우 ALB Ingress Controller 설치 매뉴얼을 참고

ALB Ingress Controller 활용 실습

다양한 예제가 존재하지만 이번 게시글에서는 Hostpath 기반 라우팅 예제를 살펴보겠습니다.

우선, Nodeport, Deployment, Replicaset, Pod를 활용하여 예제용 워크로드를 활용하여 오브젝트들을 구성해보겠습니다.

호스트 기반 라우팅 예제

이 예제는 지정된 호스트에 따라 요청을 서로 다른 서비스로 라우팅하는 방법을 보여줍니다. svc.naver.com 호스트로 들어오는 모든 요청은 naver 서비스로 라우팅되며, svc.cloud.com 호스트로 들어오는 모든 요청은 cloud 서비스로 라우팅됩니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: host-ingress
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - path: /naver
        pathType: Prefix
        backend:
          service:
            name: cmp-naver
            port:
              number: 80
  - http:
      paths:
      - path: /cloud
        pathType: Prefix
        backend:
          service:
            name: cmp-cloud
            port:
              number: 80

k apply -f Ingress.yaml

정상적으로 오브젝트 생성이 완료된 이후 네이버클라우드 콘솔에 Loadbalancer를 확인해보면 자동으로 LB가 생성되며, 생성된 접속정보를 통해 Path 기반의 라우팅이 정상적으로 되는지 확인해 보겠습니다.

http://접속정보/cloud

정상적으로 지정한 cloud의 service로 트래픽이 포워딩 되는 것을 확인 할 수 있습니다.

마치며

꿀팁으로 kubectl 자동 완성 및 단축 명령을 통해 쉽게 컨트롤하도록 설정해보자.

리눅스에서 bash 자동 완성 사용하기

Bash의 kubectl 자동 완성 스크립트는 kubectl completion bash 명령으로 생성할 수 있다. 셸에서 자동 완성 스크립트를 소싱(sourcing)하면 kubectl 자동 완성 기능이 활성화된다

그러나, 자동 완성 스크립트는 bash-completion에 의존하고 있으며, 이 소프트웨어를 먼저 설치해야 한다(type _init_completion 을 실행하여 bash-completion이 이미 설치되어 있는지 확인할 수 있음)..

bash-completion 설치
bash-completion은 많은 패키지 관리자에 의해 제공된다(여기 참고). apt-get install bash-completion 또는 yum install bash-completion 등으로 설치할 수 있다.
위의 명령은 bash-completion의 기본 스크립트인 /usr/share/bash-completion/bash_completion 을 생성한다. 패키지 관리자에 따라, ~/.bashrc 파일에서 이 파일을 수동으로 소스(source)해야 한다.
확인하려면, 셸을 다시 로드하고 type _init_completion 을 실행한다. 명령이 성공하면, 이미 설정된 상태이고, 그렇지 않으면 ~/.bashrc 파일에 다음을 추가한다.

source /usr/share/bash-completion/bash_completion

셸을 다시 로드하고 type _init_completion 을 입력하여 bash-completion이 올바르게 설치되었는지 확인한다.

kubectl 자동 완성 활성화

이제 kubectl 자동 완성 스크립트가 모든 셸 세션에서 제공되도록 해야 한다. 이를 수행할 수 있는 두 가지 방법이 있다.


kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null

kubectl에 대한 앨리어스(alias)가 있는 경우, 해당 앨리어스로 작업하도록 셸 자동 완성을 확장할 수 있다.

echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -o default -F __start_kubectl k' >>~/.bashrc

참고: bash-completion은 /etc/bash_completion.d 에 있는 모든 자동 완성 스크립트를 소싱한다.

두 방법 모두 동일하다. 셸을 다시 로드하면, kubectl 자동 완성 기능이 작동할 것이다. 셸의 현재 세션에서 bash 자동 완성을 활성화하려면 exec bash를 실행한다.

exec bash


답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다