반응형

AWS 에서 Kubernetes 사용하는 방법은 Managed Service 인 EKS 서비스를 신청/설치 방법과 일반 VM 에 Kubernetes 를 설치하는 방법이 있다.

VM 에 Kubernetes 를 설치하는 방법은 VM 을 생성하고 필요한 Security Group 을 지정하고 Muti Control plane 에 ELB 를 연결하여 다중 Master 로 사용가능 하도록 세팅해야할 내용이 제법 있다. Kubernetes 자체 설치도 kubeadm 이나 kubespray 같은 툴을 사용해서 설치한다. - 역시 쉽지 않은 내용임에 분명하다.

 

Cluster API 란 ?

지금 소개하는 방법은 Kubernetes Cluster Lifecycle SIG 에서 개발하고 있는 Cluster API 로 Operator Pattern 을 활용하여 Kubernetes 를 설치하는 방법이다. Cluster API 란 Management Kubernetes Cluster 에 Custom Controller 를 설치하고 Custom Resource 를 생성하면 자동으로 Cloud 에 VM 을 생성하고 Kubernetes 를 설치하는 방법이다. Controller 로 관리하기 때문에 VM 이 죽으면 다시 살려주는 장점이 있다. Kubernetes 가 설치된 VM 이 다운되었을 때 Self healing 으로 Recovering 해준다니 정말 멋진 아이디어인 것 같다.

Cluster API 의 시작은 2년 정도 전부터 시작되었는데 초장기에는 PoC 정도였다면 지금은 어느 정도 안정화 되어 사용하기에 문제가 없다.

개념을 보면 Management Kubernetes Cluster 를 설치(Kind, Minikube 등도 가능)하고 여기에 필요한 여러 Custom Controller 를 실행시킨다. 그리고 나서 Custom Resource 를 생성하면 지정된 Cloud 에 VM 을 생성하고 Workload Kubernetes Cluster (고객이 사용할 클러스터) 를 자동으로 생성해 주는 방법이다.

 

Cluster API 구성도

 

그림에서 보면 좌측 맨 위에 Cluster API Controller 가 있다. Cluster API Controller 는 마치 java class 로 치면 Abstraction Class 의 역활과 동일하다. Cluster Pod Network, Control Plane VM 갯수, Node VM 갯수 등을 관리한다.

이렇게 정의를 하면 Boostrap provider Controller 에서 kubeadm 으로 어떻게 Kubernetes 를 설치할 지를 관리한다.

Infrastructure provider Controller 에서는 AWS, Azure, GCP 와 같이 Public Cloud 의 자원 생성을 관리한다.

마지막으로 Control Plane provider Controller 특별하게 Control Plane 의 설치를 관리한다.

우측 위는 Custom Resource 를 보여주고 있다.

 

Cluster API Provider Controller 와 Infrastructure Provider Controller 의 상관 관계를 보면 다음과 같다.

 

Cluster API 는 Infrastructure Provider 에게 이런 식으로 구현을 해야 한다고 알려주는 가이드라고 보면 된다.

이제 세부적으로 하나씩 살펴보자.

 

Cluster API Controller

Cluster API Controller 는 cluster 의 기본 정보를 관리하는 Controller 이다. 이 Controller 가 관리하는 Custom Resource 는 다음과 같이 4개가 있다.

  • clusters
  • machinedeployments
  • machinehealthchecks
  • machines

이 중에서 machinehealthchecks 는 AWS Provider 에서는 사용하고 있지 않으므로 이를 제외하고 나머지 3가지만 살펴보겠다.

clusters CR(Custom Resource) 는 다음과 같은 정보를 가지고 있다.

  • Cluster Pod Network 정보
  • Kubernetes API url 정보
  • Control Plane 을 생성하는 CR 정보
  • Cloud Infrastructure 로 사용되는 CR 정보
  Cluster Network:
    Pods:
      Cidr Blocks:
        192.168.0.0/16
  Control Plane Endpoint:
    Host:  capi-quickstart-apiserver-479433786.ap-northeast-2.elb.amazonaws.com
    Port:  6443
  Control Plane Ref:
    API Version:  controlplane.cluster.x-k8s.io/v1alpha3
    Kind:         KubeadmControlPlane
    Name:         capi-quickstart-control-plane
    Namespace:    capi-quickstart
  Infrastructure Ref:
    API Version:  infrastructure.cluster.x-k8s.io/v1alpha3
    Kind:         AWSCluster
    Name:         capi-quickstart
    Namespace:    capi-quickstart

 

machinedeployments CR 의 정보는 Kubernetes Worker Node 에 대한 일반적인 내용이며 아래의 내용을 포함한다.

  • Bootstrap 으로 사용될 Kubeadm Config Template
  • Infrastructure Provider 에 대한 VM 정보 Template
  • Cluster name 및 Kubernetes Version 정보
  Cluster Name:               capi-quickstart
  Min Ready Seconds:          0
  Progress Deadline Seconds:  600
  Replicas:                   3
  Revision History Limit:     1
  Selector:
    Match Labels:
      cluster.x-k8s.io/cluster-name:     capi-quickstart
      cluster.x-k8s.io/deployment-name:  capi-quickstart-md-0
  Strategy:
    Rolling Update:
      Max Surge:        1
      Max Unavailable:  0
    Type:               RollingUpdate
  Template:
    Metadata:
      Labels:
        cluster.x-k8s.io/cluster-name:     capi-quickstart
        cluster.x-k8s.io/deployment-name:  capi-quickstart-md-0
    Spec:
      Bootstrap:
        Config Ref:
          API Version:  bootstrap.cluster.x-k8s.io/v1alpha3
          Kind:         KubeadmConfigTemplate
          Name:         capi-quickstart-md-0
      Cluster Name:     capi-quickstart
      Infrastructure Ref:
        API Version:  infrastructure.cluster.x-k8s.io/v1alpha3
        Kind:         AWSMachineTemplate
        Name:         capi-quickstart-md-0
      Version:        v1.20.5

 

machines CR 은 Kubernetes Control Plane VM 별 정보와 Kubernetes Worker Node VM 별 정보를 갖고 있는데 둘다 아래의 정보를 동일하게 갖고 있다.

  • Boostrap 으로 KubeadmConfig CR 정보
  • Infrastructure 로서 AWSMachine CR 정보
  Bootstrap:
    Config Ref:
      API Version:     bootstrap.cluster.x-k8s.io/v1alpha3
      Kind:            KubeadmConfig
      Name:            capi-quickstart-md-0-7f4xk
      Namespace:       capi-quickstart
      UID:             7b095ef9-3380-45cc-950e-9bce8602f954
    Data Secret Name:  capi-quickstart-md-0-7f4xk
  Cluster Name:        capi-quickstart
  Infrastructure Ref:
    API Version:  infrastructure.cluster.x-k8s.io/v1alpha3
    Kind:         AWSMachine
    Name:         capi-quickstart-md-0-dcdcx
    Namespace:    capi-quickstart
    UID:          3383bd5b-1040-4577-a690-741c556d1076
  Provider ID:    aws:///ap-northeast-2a/i-090230ea1d12065ce
  Version:        v1.20.5

 

Bootstrap Provider Controller

Bootstrap provider controller 는 Kubernetes 를 설치하는 kubeadm 관련 정보를 가지고 있다.

  • kubeadmconfigs
  • kubeadmconfigtemplates

kubeadmconfigs 는 kubeadm 으로 kubernetes 를 설치할 때 사용하는 정보로서 Control Plane VM 별 정보와 Work Node VM별 정보를 갖고 있다.

  • Cluster Configuration 으로 provider 정보를 갖고 있다.
  • Join Configuration 으로 Token 정보를 갖고 있다.
  Cluster Configuration:
    API Server:
      Extra Args:
        Cloud - Provider:  aws
    Controller Manager:
      Extra Args:
        Cloud - Provider:  aws
    Dns:
    Etcd:
    Networking:
    Scheduler:
  Join Configuration:
    Control Plane:
      Local API Endpoint:
        Advertise Address:
        Bind Port:          0
    Discovery:
      Bootstrap Token:
        API Server Endpoint:  capi-quickstart-apiserver-479433786.ap-northeast-2.elb.amazonaws.com:6443
        Ca Cert Hashes:
          sha256:de8ef58efd55489531f681066eb77cec21a7d7f8e2a04eb41a06ad38b18d066e
        Token:                        xxxx.xxxxxxxxxxx
        Unsafe Skip CA Verification:  false
    Node Registration:
      Kubelet Extra Args:
        Cloud - Provider:  aws
      Name:                {{ ds.meta_data.local_hostname }}

 

kubeadmconfigtemplates 는 Worker Node 가 join 한 template 정보로 Node 명을 가진다.

  Template:
    Spec:
      Join Configuration:
        Node Registration:
          Kubelet Extra Args:
            Cloud - Provider:  aws
          Name:                {{ ds.meta_data.local_hostname }}

 

Infrastructure Provider Controller

Infrastructure Provider Controller 는 각각의 Cloud 의 API 를 활용하여 리소스를 관리하는 Controller 로 aws 의 경우에는 아래의 정보를 가진다.

  • awsclustercontrolleridentities
  • awsclusterroleidentities
  • awsclusters
  • awsclusterstaticidentities
  • awsfargateprofiles
  • awsmachinepools
  • awsmachines
  • awsmachinetemplates
  • awsmanagedclusters
  • awsmanagedmachinepools

이 중에서 awsclusters, awsmachines, awsmachinetemplate 3가지만 살펴본다.

awsclusters 는 aws 에 설치된 Kubernetes workload cluster 에 대한 정보를 갖고 있다.

  Bastion:
    Allowed CIDR Blocks:
      0.0.0.0/0
    Enabled:  false
  Control Plane Endpoint:
    Host:  capi-quickstart-apiserver-479433786.ap-northeast-2.elb.amazonaws.com
    Port:  6443
  Identity Ref:
    Kind:  AWSClusterControllerIdentity
    Name:  default
  Network Spec:
    Cni:
      Cni Ingress Rules:
        Description:  bgp (calico)
        From Port:    179
        Protocol:     tcp
        To Port:      179
        Description:  IP-in-IP (calico)
        From Port:    -1
        Protocol:     4
        To Port:      65535
    Subnets:
      Availability Zone:  ap-northeast-2a
      Cidr Block:         10.0.0.0/20
      Id:                 subnet-04e972e6bfcb98336
      Is Public:          true
      Nat Gateway Id:     nat-0d456fe6c4dd2ce3d
      Route Table Id:     rtb-0dfccca96ffc00732
      Tags:
        Name:                                                          capi-quickstart-subnet-public-ap-northeast-2a
        kubernetes.io/cluster/capi-quickstart:                         shared
        kubernetes.io/role/elb:                                        1
        sigs.k8s.io/cluster-api-provider-aws/cluster/capi-quickstart:  owned
        sigs.k8s.io/cluster-api-provider-aws/role:                     public
      Availability Zone:                                               ap-northeast-2a
      Cidr Block:                                                      10.0.64.0/18
      Id:                                                              subnet-06f2be3eedb46d622
      Is Public:                                                       false
      Route Table Id:                                                  rtb-00090ad5d1de60b20
      Tags:
        Name:                                                          capi-quickstart-subnet-private-ap-northeast-2a
        kubernetes.io/cluster/capi-quickstart:                         shared
        kubernetes.io/role/internal-elb:                               1
        sigs.k8s.io/cluster-api-provider-aws/cluster/capi-quickstart:  owned
        sigs.k8s.io/cluster-api-provider-aws/role:                     private
      Availability Zone:                                               ap-northeast-2b
      Cidr Block:                                                      10.0.16.0/20
      Id:                                                              subnet-02a9eed4c602fd3a2
      Is Public:                                                       true
      Nat Gateway Id:                                                  nat-050244cb7c9cff368
      Route Table Id:                                                  rtb-020e9366a2da25625
      Tags:
        Name:                                                          capi-quickstart-subnet-public-ap-northeast-2b
        kubernetes.io/cluster/capi-quickstart:                         shared
        kubernetes.io/role/elb:                                        1
        sigs.k8s.io/cluster-api-provider-aws/cluster/capi-quickstart:  owned
        sigs.k8s.io/cluster-api-provider-aws/role:                     public
      Availability Zone:                                               ap-northeast-2b
      Cidr Block:                                                      10.0.128.0/18
      Id:                                                              subnet-03880f2f847b3c21e
      Is Public:                                                       false
      Route Table Id:                                                  rtb-06b52ab77da5c5f2c
      Tags:
        Name:                                                          capi-quickstart-subnet-private-ap-northeast-2b
        kubernetes.io/cluster/capi-quickstart:                         shared
        kubernetes.io/role/internal-elb:                               1
        sigs.k8s.io/cluster-api-provider-aws/cluster/capi-quickstart:  owned
        sigs.k8s.io/cluster-api-provider-aws/role:                     private
      Availability Zone:                                               ap-northeast-2c
      Cidr Block:                                                      10.0.32.0/20
      Id:                                                              subnet-09ccabe6dd862df6a
      Is Public:                                                       true
      Nat Gateway Id:                                                  nat-030068539013d5c64
      Route Table Id:                                                  rtb-0973a222fc772ff76
      Tags:
        Name:                                                          capi-quickstart-subnet-public-ap-northeast-2c
        kubernetes.io/cluster/capi-quickstart:                         shared
        kubernetes.io/role/elb:                                        1
        sigs.k8s.io/cluster-api-provider-aws/cluster/capi-quickstart:  owned
        sigs.k8s.io/cluster-api-provider-aws/role:                     public
      Availability Zone:                                               ap-northeast-2c
      Cidr Block:                                                      10.0.192.0/18
      Id:                                                              subnet-0be3353fd3b6f1637
      Is Public:                                                       false
      Route Table Id:                                                  rtb-0854effe818750d33
      Tags:
        Name:                                                          capi-quickstart-subnet-private-ap-northeast-2c
        kubernetes.io/cluster/capi-quickstart:                         shared
        kubernetes.io/role/internal-elb:                               1
        sigs.k8s.io/cluster-api-provider-aws/cluster/capi-quickstart:  owned
        sigs.k8s.io/cluster-api-provider-aws/role:                     private
    Vpc:
      Availability Zone Selection:    Ordered
      Availability Zone Usage Limit:  3
      Cidr Block:                     10.0.0.0/16
      Id:                             vpc-070a545cb4b967dd7
      Internet Gateway Id:            igw-03a4ee0ca0f8d0f72
      Tags:
        Name:                                                          capi-quickstart-vpc
        sigs.k8s.io/cluster-api-provider-aws/cluster/capi-quickstart:  owned
        sigs.k8s.io/cluster-api-provider-aws/role:                     common
  Region:                                                              ap-northeast-2
  Ssh Key Name:                                                        capi-seungkyu

 

awsmachinetemplates 은 aws vm spec 에 대한 정보를 template 으로 갖고 있다. template 은 control plane 과 worker node 각 1개씩 가진다.

 

control plane template

  Template:
    Spec:
      Iam Instance Profile:  control-plane.cluster-api-provider-aws.sigs.k8s.io
      Instance Type:         t3.large
      Ssh Key Name:          capi-seungkyu

worker node template

  Template:
    Spec:
      Iam Instance Profile:  nodes.cluster-api-provider-aws.sigs.k8s.io
      Instance Type:         t3.large
      Ssh Key Name:          capi-seungkyu

 

awsmachines 은 awsmachinetemplates 으로 연결된 control plane 과 worker node 별 aws VM 에 대한 정보를 갖는다.

 

contol plane vm1

  Ami:
  Cloud Init:
    Secure Secrets Backend:  secrets-manager
  Iam Instance Profile:      control-plane.cluster-api-provider-aws.sigs.k8s.io
  Instance ID:               i-0433d589b68e42cd0
  Instance Type:             t3.large
  Provider ID:               aws:///ap-northeast-2c/i-0433d589b68e42cd0
  Ssh Key Name:              capi-seungkyu

 

Control plane Provider Controller

Control plane provider controller 는 Kubernetes control plane 에 대한 정보를 관리하는 Controller 이다.

  • kubeadmcontrolplanes

kubeadmcontrolplanes 은 말그래도 control plane 의 정보를 담고 있으며 앞에서 살펴본 정보들을 활용한다.

  • Infrastructure Template 으로 AWSMachineTemplate 을 사용
  • Kubeadm Config 로 Init Configuration 과 Join Configuration 정보
  • Replicas 개수 정보
  • Kubernetes version 정보
  Infrastructure Template:
    API Version:  infrastructure.cluster.x-k8s.io/v1alpha3
    Kind:         AWSMachineTemplate
    Name:         capi-quickstart-control-plane
    Namespace:    capi-quickstart
  Kubeadm Config Spec:
    Cluster Configuration:
      API Server:
        Extra Args:
          Cloud - Provider:  aws
      Controller Manager:
        Extra Args:
          Cloud - Provider:  aws
      Dns:
      Etcd:
      Networking:
      Scheduler:
    Init Configuration:
      Local API Endpoint:
        Advertise Address:
        Bind Port:          0
      Node Registration:
        Kubelet Extra Args:
          Cloud - Provider:  aws
        Name:                {{ ds.meta_data.local_hostname }}
    Join Configuration:
      Discovery:
      Node Registration:
        Kubelet Extra Args:
          Cloud - Provider:  aws
        Name:                {{ ds.meta_data.local_hostname }}
  Replicas:                  3
  Rollout Strategy:
    Rolling Update:
      Max Surge:  1
    Type:         RollingUpdate
  Version:        v1.20.5

 

반응형
Posted by Kubernetes Korea co-leader seungkyua@gmail.com

댓글을 달아 주세요

반응형

 

https://www.youtube.com/watch?v=lIzAMFUKxBE&t=4s

반응형
Posted by Kubernetes Korea co-leader seungkyua@gmail.com

댓글을 달아 주세요

반응형

 

https://www.youtube.com/watch?v=HNGEo7Kd3_k&t=3s

 

반응형
Posted by Kubernetes Korea co-leader seungkyua@gmail.com

댓글을 달아 주세요

반응형

Argo Rollout 은 new version pods 와 old version pods 를 어떻게 구분하는 것일까? Rollout 리소스로 생성하면 ReplicaSet 의 형태인 Pod 템플릿 영역인 (spec.template) 과 동일하다. 즉 ReplicaSet 이 Selector 로 지정한 label 로 Pod 를 찾아가는 것이다.

아래 Rollout 1개와 Service 2개를 가지는 sample yaml 파일을 배포하여 동작 방법을 살펴보자.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-bluegreen
spec:
  replicas: 2
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: rollout-bluegreen
  template:
    metadata:
      labels:
        app: rollout-bluegreen
    spec:
      containers:
      - name: rollouts-demo
        image: argoproj/rollouts-demo:blue
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
  strategy:
    blueGreen:
      activeService: rollout-bluegreen-active
      previewService: rollout-bluegreen-preview
      autoPromotionEnabled: false

---
kind: Service
apiVersion: v1
metadata:
  name: rollout-bluegreen-active
spec:
  selector:
    app: rollout-bluegreen
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

---
kind: Service
apiVersion: v1
metadata:
  name: rollout-bluegreen-preview
spec:
  selector:
    app: rollout-bluegreen
  ports:
  - protocol: TCP
    port: 80

Rollout 은 strategy 만 제외하면 ReplicaSet 혹은 Deployment 와 동일하다. 그래서 Rollout 을 배포하면 ReplicaSet 과 Pod 는 Kubernetes Core Resource 타입으로 동일하게 생성되고 조회할 수 있다.

 

.spec.selector.matchLabels 와 .spec.template.metadata.labels 에서 지정한 label 은 동일해야 한다. 이 부분은 ReplicaSet 에서 요구하는 spec 과 같다.

 

strategy 의 blueGreen 에는 rollout-bluegreen-active 와 rollout-bluegreen-preview 라는 service 가 2개가 지정되어 있다. Service 는 DNS 명 처럼 이름으로 IP 를 매칭하는 값을 가지는 기능과 Pod 를 연결하여 load balancing 해주는 대표적인 기능이 있다. rollout-bluegreen-active Service 에는 selector 로 "app: rollout-bluegreen" 값이 지정되어 있는데 이는 Rollout Template 에서 지정된 Pod 의 labels 를 가리킨다.

 

그런데 rollout-bluegreen-active Service 와 rollout-bluegreen-preview 2개 모두 같은 selector 로 같은 Pod 를 보고 있는데 어떻게 new version 과 old version 을 구분할까?

 

배포한 후에 설정들이 어떻게 바뀌는지 살펴보자.

$ kubectl apply -f rollout-blue-green.yaml
$ kubectl argo rollouts get rollout rollout-bluegreen --watch

 

 

rollout 명이 rollout-bluegreen-[해시코드값] 으로 되어 있는데 여기서 해시코드 값이 6565b74f44 은 ReplicaSet 의 해시코드와 동일하다.

$ kubectl get rs rollout-bluegreen

 

 

이 해시코드 값은 Service 에서도 찾아 볼 수 있다.

$ kubectl get svc rollout-bluegreen-active -o yaml
...
apiVersion: v1
kind: Service
metadata:
  name: rollout-bluegreen-active
  namespace: default
spec:
  clusterIP: 10.233.59.133
  clusterIPs:
  - 10.233.59.133
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: rollout-bluegreen
    rollouts-pod-template-hash: 6565b74f44
  sessionAffinity: None
  type: ClusterIP
...

selector 의 label 에 자동으로 rollouts-pod-template-hash: 6565b74f44 이 추가되어 rollout-bluegreen-active Service 는 현재 version 의 rollout 으로 생성된 Pod 를 가리키는 것을 알 수 있다.

이제 이미지를 업데이트 하여 upgrade 배포를 해보자.

$ kubectl argo rollouts set image rollout-bluegreen rollouts-demo=argoproj/rollouts-demo:yellow
$ kubectl argo rollouts get rollout rollout-bluegreen --watch

 

 

revision:2 아래에 rollout-bluegreen-6b5dc99488 이라는 새로운 해시코드 값으로 ReplicaSet 이 생성되었다.

rollout-bluegreen-preview Service 의 selector 로 지정된 labels 을 보면 rollouts-pod-template-hash:6b5dc99488 가 생성되어 new version 의 pod 를 가리키는 것을 알 수 있다.

$ kubectl get svc rollout-bluegreen-preview -o yaml
...
apiVersion: v1
kind: Service
metadata:
  name: rollout-bluegreen-preview
  namespace: default
spec:
  clusterIP: 10.233.44.227
  clusterIPs:
  - 10.233.44.227
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: rollout-bluegreen
    rollouts-pod-template-hash: 6b5dc99488
  sessionAffinity: None
  type: ClusterIP
...

배포를 완료하고 ReplicaSet 을 조회해 보면 이전 해시코드 값을 갖는 ReplicaSet 의 DESIRED, CURRENT, READY 가 0 으로 세팅되어 있는 것을 알 수 있다.

$ kubectl argo rollouts promote rollout-bluegreen
$ kubectl get rs -l app=rollout-bluegreen
NAME                           DESIRED   CURRENT   READY   AGE
rollout-bluegreen-6565b74f44   0         0         0       5h35m
rollout-bluegreen-6b5dc99488   2         2         2       10m

이 방식을 응용하면 Deployment 로도 쉽게 배포 전략을 활용할 수 있다.

반응형
Posted by Kubernetes Korea co-leader seungkyua@gmail.com

댓글을 달아 주세요

반응형

Argo rollout 은 Progressive Delivery 를 지원하는 툴이다.

아래의 그림에서 보듯이 Canary 배포를 진행할 때 일시적으로 배포를 홀딩한 상태에서 new version 에 대한 배포가 성공되었는지를 Metric 으로 판단하여 안전하게 배포를 완료할 수 있다. (metric 수집과 쿼리는 Prometheus 를 포함하여 다양한 모니터링 툴을 지원한다.)

 

 

Metric 을 통해 배포의 성공 여부를 판단하여 rollback 할 것인지, 계속 진행할 것인지를 결정할 수 있다는 것이 중요한 키 포인트다. 왜냐하면 쿠버네티스의 롤링 업데이트는 readiness 로 배포 성공여부를 판단하는데 이는 Metric 보다 판단하기에 부족할 수 있고, 중간에 에러가 발생하면 멈출 수 는 있지만 자동으로 rollback 되지는 않기 때문이다. 

Argo Quick 설치하기

# kubectl create namespace argo-rollouts
# kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

 

kubectl plugin 설치하기

# curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64
# chmod +x ./kubectl-argo-rollouts-linux-amd64
# mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts
# kubectl argo rollouts version

 

 

Basic rollout 설치하기

# cd ~/argo-rollout-demo
# curl -Lo basic-rollout-blue.yaml https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/rollout.yaml
# curl -Lo basic-service.yaml https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/service.yaml

# kubectl apply -f basic-rollout-blue.yaml
# kubectl apply -f basic-service.yaml

# kubectl patch svc rollouts-demo --patch \
'{"spec": { "type": "NodePort", "ports": [ { "nodePort": 31080, "port": 80, "protocol": "TCP", "targetPort": "http", "name": "http" } ] } }'

 

 

화면 접속

http://k2-master01:31080

콘솔 보기

# kubectl argo rollouts get rollout rollouts-demo --watch

 

Basic rollout Canary 업그레이드

# kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow

rollout 전략이 처음 step 은 20% 만 변경하는 것이기 때문에 5개의 replica 중에 1개만 old version(blue) 이고 4 개는 new version(yellow) 이다. 그리고 현재는 pause (일시멈춤) 상태로 더이상 rollout 배포가 진행되지 않고 있다.

 

 

Basic rollout Canary 업그레이드 계속 진행

# kubectl argo rollouts promote rollouts-demo

 

promote 로 계속 rollout 업그레이드를 진행하면 점차 new version 이 revision:2 영역인 canary 로 replica 개수를 증가시키는 것을 볼 수 있다. duration 을 10으로 주었기 때문에 10 초 단위로 20% 씩 자동으로 올려준다.

 

일정 시간이 다 지나면 전체가 전부 다 업그레이드 된다.

 

argo rollout 은 metric 으로 정의한 성공 여부에 따라 배포를 계속 진행할 것인지 아니면 abort 시킬 것인지를 자동으로 결정할 수 있다.

 

출처: https://argoproj.github.io/argo-rollouts

반응형
Posted by Kubernetes Korea co-leader seungkyua@gmail.com

댓글을 달아 주세요

반응형

Kubernetes 기반의 monitoring 을 구현한다면 최우선 순위로 검토되는 오픈소스는 단연 Prometheus 이다. 최근에는 Kubernetes 위에 실행되는 Pod와 같은 자원을 효과적으로 관리하기 위해서 Operator 를 활용하고 있는 추세인데 이에 맞춰 Prometheus 에서도 Operator 를 지원하고 있다. 일반적으로 Operator 는 중심이 되는 프로그램, Pod 와 같이 CustomResource를 정의하면 자동으로 해당 프로그램을 띄우는 방식으로 사용된다. 하지만 Prometheus Operator Prometheus 자체를 띄우고 관리하는 방식이 아니라 Prometheus 에서 사용되는 설정 등을 관리하기 위해서 사용된다. 한마디로 말하면 Prometheus OperatorPrometheus 를 모두 설치하고, Operator Prometheus 설정을 CustomResource 로 관리하는 방식이다.

 

그럼 이제 Prometheus Operator Prometheus 를 설치해 보자. 둘다 모두 prometheus-community 에서 제공하는 helm chart helm3 를 이용하여 설치한다.

 

helm repo 를 아래와 같이 등록한다.

$ helm repo add prometheus https://prometheus-community.github.io/helm-charts
$ helm repo update

$ helm search repo prometheus

 

많은 차트들이 검색되는데 그중에서 kube-prometheus-stack chart Prometheus Operator Prometheus 를 설치한다.

 

1. Prometheus Operator 설치

helm chart 에서 Oeveride value 를 아래와 같이 지정한다.

# vi prometheus-operator-values.yaml

namespaceOverride: prometheus
fullnameOverride: prometheus-operator
defaultRules:
  create: false
alertmanager:
  enabled: false
grafana:
  enabled: false
kubeApiServer:
  enabled: false
kubelet:
  enabled: false
kubeControllerManager:
  enabled: false
coreDns:
  enabled: false
kubeDns:
  enabled: false
kubeEtcd:
  enabled: false
kubeScheduler:
  enabled: false
kubeProxy:
  enabled: false
kubeStateMetrics:
  enabled: false
nodeExporter:
  enabled: false
prometheus:
  enabled: false
prometheusOperator:
  enabled: true
  resources:
    limits:
      cpu: 2
      memory: 2Gi
    requests:
      cpu: 1
      memory: 1Gi
  serviceMonitor:
    selfMonitor: false
  nodeSelector:
    monitoring: enabled
  createCustomResource: true
  cleanupCustomResource: true
  cleanupCustomResourceBeforeInstall: true

 

Prometheus Operator 를 설치할 namespacenamespaceOverride prometheus 로 지정한다.

Deployments 로 생성될 이름은 fullnameOverride prometheus-operator 로 지정한다.

Operator 만 명시적으로 생성할 의도로 나머지 prometheus, exporter, alertmanager 등은 enabled: false 로 지정하여 생성하지 않는다.

 

Prometheus Operator 가 생성될 노드를 nodeSelector 로 지정할 수 있으며 여기서는 monitoring: enabled 로 세팅했으므로 Kubernetes node 에 해당 label 이 설정된 노드가 있어야 한다.

 

$ kubectl create ns prometheus
$ kubectl label namespace prometheus name=prometheus

$ kubectl label node k1-node01 monitoring=enabled
$ kubectl label node k1-node02 monitoring =enabled
$ kubectl label node k1-node03 monitoring =enabled

$ kubectl create secret generic etcd-client-cert -n prometheus \
--from-file=etcd-ca=/etc/ssl/etcd/ssl/ca.pem \
--from-file=etcd-client=/etc/ssl/etcd/ssl/member-k1-master01.pem \
--from-file=etcd-client-key=/etc/ssl/etcd/ssl/member-k1-master01-key.pem

 

 

prometheus namespace labelname=prometheus 로 준 이유는 나중에 CustomeResource Service Monitor prometheus namespace 안에 생성되면 자동으로 해당 설정을 적용하기 위해서 Operator 에 알려주는 정보이다. 별도로 설정하지 않아도 prometheus namesapce 에는 자동으로 설정된다.

 

또 한가지 알아야 할 것은 etcd metric 을 가져오기 위해서는 endpoint 뿐만이 아니라 mTLS 인증서도 있어야 한다. kubernetes kubespary 로 설치하였다면 master 노드의 해당 위치에 etcd 인증서가 있으니 이를 가지고 secret 을 미리 생성해 놓아야 metric 을 가져올 수 있다.

 

이제 helm 명령어로 Prometheus Operator를 설치한다. upgrade -i 옵션을 주면 설치가 안되어 있을 경우에는 create 명령과 동일하고 설치가 되어 있을 경우에는 upgrade 명령과 동일하다.

 

$ helm upgrade -i prometheus-operator prometheus/kube-prometheus-stack --version 14.0.1 -f prometheus-operator-values.yaml -n prometheus

 

 

 

2. Prometheus 설치

 

동일한 kube-prometheus-stack 차트로 prometheus 를 설치한다.

 

# vi prometheus-values.yaml

defaultRules:
  create: false
alertmanager:
  enabled: true
  service:
    type: NodePort
    nodePort: 30903
  alertmanagerSpec:
    nodeSelector:
      monitoring: enabled
grafana:
  enabled: false
kubeApiServer:
  enabled: true
  serviceMonitor:
    namespaceSelector:
      matchNames:
      - default
kubeEtcd:
  enabled: true
  endpoints:
    - 192.168.30.13
    - 192.168.30.14
    - 192.168.30.15
  serviceMonitor:
    scheme: https
    insecureSkipVerify: false
    serverName: localhost
    caFile: /etc/prometheus/secrets/etcd-client-cert/etcd-ca
    certFile: /etc/prometheus/secrets/etcd-client-cert/etcd-client
    keyFile: /etc/prometheus/secrets/etcd-client-cert/etcd-client-key
kubeStateMetrics:
  enabled: false
nodeExporter:
  enabled: false
prometheusOperator:
  enabled: false
  serviceMonitor:
    selfMonitor: true
prometheus:
  enabled: true
  service:
    type: NodePort
    nodePort: 30008
  # Service for thanos service discovery on sidecar
  # Enable this can make Thanos Query can use
  # `--store=dnssrv+_grpc._tcp.${kube-prometheus-stack.fullname}-thanos-discovery.${namespace}.svc.cluster.local` to discovery
  # Thanos sidecar on prometheus nodes
  # (Please remember to change ${kube-prometheus-stack.fullname} and ${namespace}. Not just copy and paste!)
  thanosService:
    enabled: false
    annotations: {}
    labels: {}
    portName: grpc
    port: 10901
    targetPort: "grpc"
  thanosIngress:
    enabled: false
    type: NodePort
    nodePort: 30901
  prometheusSpec:
    externalLabels:
      cluster: k1
    nodeSelector:
      monitoring: enabled
    secrets:
      - etcd-client-cert
    ruleNamespaceSelector:
      matchLabels:
        name: prometheus
    ruleSelectorNilUsesHelmValues: false
    serviceMonitorNamespaceSelector:
      matchLabels:
        name: prometheus
    serviceMonitorSelectorNilUsesHelmValues: false
    podMonitorNamespaceSelector:
      matchLabels:
        name: prometheus
    podMonitorSelectorNilUsesHelmValues: false
    retention: 10d
    replicas: 1
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: rbd
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 100Gi
    ## ref: https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#thanosspec
    thanos:
      version: v0.18.0

 

 

kubeEtcd etcd master 3대에 설치되어 있어 endpoint에 해당 ip 를 모두 넣었으며 caFile, certFile, keyFile 은 앞서 설치한 secret 명을 경로로 포함하고 있다. alertmanager prometheus 모두 nodePort 로 설치하여 접근할 수 있다.

serviceMonitorNamespaceSelector podMonitorNamespaceSelector 를 지정하여 Monitor 할 대상을 CustomResource 를 통해 자동으로 설정할 수 있다. 앞서 prometheus namespace 를 생성할 때 label name=prometheus 로 지정한 이유가 바로 이 부분이다.

마지막으로 Prometheus 가 사용할 storage class rbd 로 지정하여 자동으로 생성되게 설정한다.

 

helm 으로 Prometheus 를 설치하는 명령은 다음과 같다.

 

$ helm upgrade -i prometheus prometheus/kube-prometheus-stack --version 14.0.1 -f prometheus-values.yaml -n prometheus

 

 

Prometheus 접속 url: http://<node-ip>:30008

 

 

alertmanager 접속 url: http://<node-ip>:30903

반응형
Posted by Kubernetes Korea co-leader seungkyua@gmail.com

댓글을 달아 주세요