Rancher 설치 이후 다른 클러스터를 현재 설치된 Rancher에 연동 시켜 보자.

Import Existing 

Import Existing 버튼 클릭

각각 사용되고 있는 Provider 가 있다면 EKS, AKS, GKE 를 선택하자.

여기선 on-premise 에 설치 된 Cluster를 추가하는 것으로 한다.

Generic 클릭

 

Cluster 추가

Cluster Name: 추가할 Cluster의 Kubernetes api 주소

Cluster Description: Cluster 설명

위에 설명된 명령어들을 입력해서 RBAC 설정을 하자

$ kubectl apply -f https://rancher.io/v3/import/9b6594h6cjkdw5vs282ssgzkzngxmspxwzdmwn84vdrxvr9tnc7zq8_c-m-mwrw6rkt.yaml
clusterrole.rbac.authorization.k8s.io/proxy-clusterrole-kubeapiserver unchanged
clusterrolebinding.rbac.authorization.k8s.io/proxy-role-binding-kubernetes-master unchanged
namespace/cattle-system unchanged
serviceaccount/cattle unchanged
clusterrolebinding.rbac.authorization.k8s.io/cattle-admin-binding unchanged
secret/cattle-credentials-e42d12d created
clusterrole.rbac.authorization.k8s.io/cattle-admin unchanged
deployment.apps/cattle-cluster-agent configured
service/cattle-cluster-agent created


$ kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user kubernetes-admin
clusterrolebinding.rbac.authorization.k8s.io/cluster-admin-binding created

RBAC 설정이 정상적으로 완료되면 자동적으로 Pending 상태에서 Active 상태로 변경이 완료되며 연동이 완료된다.

Cluster 추가

추가 후 메뉴에서 추가된 Cluster의 목록을 볼 수 있다.

Cluster Dashboard

추가된 Cluster 선택 시 위와 같이 Cluster Dashboard에서 간단한 Status들을 확인 할 수 있다.

반응형
Posted by 사용자 guru_k

댓글을 달아 주세요

결혼을 앞두고 임장을 다녀봤는데 집값이.. 장난이 아니였다.

실제로 집값이 오르고 있다고 뉴스에선 많이 봤지만 겪어보니 이건 뭐...

엎친데 덮친격으로 정부에서는 대출 규제에 나서게 되고 도저히 괜찮은 지역에 집을 구하기가 너무 힘들거 같았다.

그래도 11월부터 신혼특공의 소득제한이 달라진다고 하니 전세로 지내면서 신혼특공으로 청약이 노려보려 한다. (신혼 특공 개선 방안)

 

지난 8월쯤 정부가 신규 대출 규제와 더불어 대다수의 은행에서 한도가 초과되어 신규 대출이 불가능하다는 얘기가 나왔다. 그러나 다행히도 규제가 풀리면서 다시 신규 전세자금대출을 받기 시작했고 기존 카카오뱅크와 같은 인터넷전문은행도 22일부터 신규 전세자금대출을 받는다는 얘기가 들려왔다.

 

연말에 계약이 종료되고 이사를 해야하는 입장에서 그리고 결혼을 하게 되면서 집을 옮겨야 했는데 다행히도 규제가 풀리면서 대출을 받을 수 있을 것 같았다.

 

전세 자금 가능 여부 알아보기

먼저 규제가 풀렸다고 하더라도 대출 상황 자체가 매우 불안하여 신규 전세자금대출이 가능 여부를 확인하고 싶었다. 대출 가능 여부를 확인하기 위해서 인터넷 여러군데 정보를 확인해보았으나 찾기가 쉽지 않았다.

그래서 처음엔 주거래은행이면서 기존에 대출을 이용했던적있는 우리은행에 전화해서 물어봤지만 규제가 풀렸음에도 우리은행은 영업점별로 한도를 초과하면 신규 전세대출을 받지 않는다고 했다..

 직장을 다니면서 은행에 가는것이 쉽지 않아서 일단은 전화로 몇군데 은행에 전화해서 대출 가능 여부를 물어봤으나 전화로는 알 수 있는 방법이 전혀 없었다.

그래서 일단은 신규 전세자금대출 가능 여부를 알아보기 위해서 은행에 직접 방문하여 대출 상담을 받아 보았으며, 내가 가져간 서류와 상태는 아래와 같았다.

  • 가계약은 하지 않았으나 어떤곳으로 이사할 예정인지 대략적인 주소를 가지고 있었음
  • 원하는 대출 금액
  • 소득증명서
  • 재직증명서
  • 원천징수영수증

이렇게 대략적인 정보와 서류들을 들고 은행에 방문해서 대출 상담을 받아보았다. 

몇군데 은행에 상담을 받아본 결과 대략적인 대출 가능 여부와 금리정도의 답변을 받을 수 있었다. 하지만 상담과정에서 내가 가져간 정보는 대략적인 주소정도였는데 정확히 상담을 받기 위해선 아파트일 경우 정확한 동과 호수를 알고 있어야 더 정확한 상담이 가능하였다.

이외에도 궁금한점이 있어 몇가지 질문을 드렸고 아래와 같이 답변을 받을 수 있었다.

  • 대출 규제가 일시적으로 풀린것은 아닐지. 전세 가계약을 하고 서류 준비과정에서 다시 대출 규제가 생길 여부는 없을지.
    • 정확히 예측하기는 힘들지만 한번 규제를 했다가 풀었기 때문에 다시 규제를 하진 않을 것이라는 것
    • 하지만 현재 금리가 주마다 높아지는 상황이라 금리에 대한 고려가 필요
  • 내년에 대출 한도가 초기화 되면 금리가 더 낮아질 일은 없을지
    • 현재 로써 알 수 있는 방법은 없으나 낮아 질 것 같진 않다는 것
  • 전세 계약 시 확인이 필요한 내용
    • 질권 설정 가능한지 
    • 임대차 조사 (계약 & 집 확인)
    • 재직확인 실사 (전화로 확인하는것이 아닌 실제 직장에 방문하여 확인하기도 한다고함)
    • 전입가능 유무

 

다행히 신규 대출 규제가 풀리면서 대출을 받아 전세로 집을 구할 수 있게 되었지만 금리가 생각보다 높아서 일단 가계약을 하고 난뒤에 좀더 발품을 팔아 봐야 겠다.

 

반응형
Posted by 사용자 guru_k

댓글을 달아 주세요

Rancher

Rancher는 다양한 인프라에 구성된 Cluster들을 손쉽게 관리해주는 툴이다. Rancher를 이용해서 사용자는 Kuberntes 를 손쉽게 배포하고 관리할 수 있다.

그럼 Rancher를 설치하고 대시보드까지 접속 해보자.

Install Rancher

Add helm repo

$ helm repo add rancher-latest https://releases.rancher.com/server-charts/latest

Create Rancher Namespace

$ kubectl create namespace cattle-system

Install cert-manager

# CustomResourceDefinition 설치
$ kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.0.4/cert-manager.crds.yaml
customresourcedefinition.apiextensions.k8s.io/certificaterequests.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/certificates.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/challenges.acme.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/clusterissuers.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/issuers.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/orders.acme.cert-manager.io created

# cert-manager namespace 추가
$ kubectl create namespace cert-manager
namespace/cert-manager created

# Add jetstack helm repo
$ helm repo add jetstack https://charts.jetstack.io
"jetstack" has been added to your repositories

# 업데이트 헬름 저장소 로컬 캐시
$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "jetstack" chart repository
...Successfully got an update from the "rancher-latest" chart repository
Update Complete. ⎈Happy Helming!⎈

# cert-manager helm chart 설치
$ helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --version v1.0.4
  
NAME: cert-manager
LAST DEPLOYED: Wed Oct 20 20:38:30 2021
NAMESPACE: cert-manager
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
cert-manager has been deployed successfully!

In order to begin issuing certificates, you will need to set up a ClusterIssuer
or Issuer resource (for example, by creating a 'letsencrypt-staging' issuer).

More information on the different types of issuers and how to configure them
can be found in our documentation:

https://cert-manager.io/docs/configuration/

For information on how to configure cert-manager to automatically provision
Certificates for Ingress resources, take a look at the `ingress-shim`
documentation:

https://cert-manager.io/docs/usage/ingress/

Verify cert-manager

# cert-manager 설치 확인
$ kubectl get pods --namespace cert-manager
NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-75dbbd5d6-kxf5j               1/1     Running   0          49m
cert-manager-cainjector-85c559fd6c-zpc2q   1/1     Running   0          49m
cert-manager-webhook-6c77dfbdb8-jfn72      1/1     Running   0          49m

Install Rancher

$ helm install rancher rancher-latest/rancher \
  --namespace cattle-system \
  --set hostname=rancher.my.org
  
NAME: rancher
LAST DEPLOYED: Wed Oct 20 20:41:25 2021
NAMESPACE: cattle-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Rancher Server has been installed.

NOTE: Rancher may take several minutes to fully initialize. Please standby while Certificates are being issued, Containers are started and the Ingress rule comes up.

Check out our docs at https://rancher.com/docs/

If you provided your own bootstrap password during installation, browse to https://localhost to get started.

If this is the first time you installed Rancher, get started by running this command and clicking the URL it generates:

```
echo https://rancher.my.org/dashboard/?setup=$(kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{.data.bootstrapPassword|base64decode}}')
```

To get just the bootstrap password on its own, run:

```
kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{.data.bootstrapPassword|base64decode}}{{ "\n" }}'
```


Happy Containering!

 

 

$ kubectl -n cattle-system rollout status deploy/rancher
Waiting for deployment "rancher" rollout to finish: 0 of 3 updated replicas are available...
Waiting for deployment "rancher" rollout to finish: 1 of 3 updated replicas are available...
Waiting for deployment "rancher" rollout to finis

Host 설정

# /etc/hosts

127.0.0.1 rancher.my.org

 

대시보드 접속

Rancher Dashboard

 

반응형
Posted by 사용자 guru_k

댓글을 달아 주세요

metrics-server 설치하기 이후에 kubectl top pod 으로 metric 확인 시 아래와 같은 에러가 발생한다면 RBAC 설정을 추가해주자.

$ kubectl top pod
pods.metrics.k8s.io is forbidden: User "front-proxy-client" cannot list resource "pods" in API group "metrics.k8s.io" in the namespace "default"

front-proxy-client 유저에 rolebinding 과 clusterolebinding을 생성해준다.

$ kubectl create rolebinding metrics-server-role --clusterrole=admin --user=front-proxy-client
rolebinding.rbac.authorization.k8s.io/metrics-server-role created

$  kubectl create clusterrolebinding metrics-server-clusterrole --clusterrole=view --user=front-proxy-client
clusterrolebinding.rbac.authorization.k8s.io/metrics-server-clusterrole created

rolebinding 후 kubectl top pod 명령어를 통해 metric 이 정상적으로 수집되었는지 확인 해보자.

$ kubectl top pod
NAME                             CPU(cores)   MEMORY(bytes)
foo-79d86fff79-rslc9             1m           80Mi
foo-599bcbb59c-8t5qc             1m           72Mi
반응형
Posted by 사용자 guru_k

댓글을 달아 주세요

metrics-server 는 kubernetes의 오토스케일링 파이프라인들에 유용한 자원으로 kubernetes autoscaler를 사용하기 위해선 필수 자원이다.

metrics-server는 kubelet으로부터 metric을 수집하고 Metric API를 통해서 kubernetes api에서 노출된다.

복잡한 말이긴 하지만 kubectl top 명령어를 사용하거나 Horizontal Pod Autoscaler, Vertical Pod Autoscaler 를 사용하기 위해선 필수적인 자원이다.

당연하겠지만 kubernetes cluster에서 설치되어야 한다.

metrics-server 설치

metrics-server를 설치하기 위해선 별도의 yaml 파일을 생성하거나 아래처럼 직접 git 에서 직접 설치가 가능하다.

$ kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

serviceaccount/metrics-server created
clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
clusterrole.rbac.authorization.k8s.io/system:metrics-server created
rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created
clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created
clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created
service/metrics-server created
deployment.apps/metrics-server created
apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created

$ kubectl get pods -n kube-system | grep metric
metrics-server-5d5d6598c7-kk6g8                            0/1     Running   0          19s

위에 처럼 설치할 경우 kubelet certificate가 필요하다. 그래서 cert validation을 피하기 위해선 --kubelet-insecure-tls flag가 필요하다 

테스트 환경에서 cert validation을 패스하고 insecure로 실행해보자.

~$ mkdir metrics-server
~$ cd metrics-server
~/metrics-server$ wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# components.yaml 파일을 오픈한뒤 아래처럼 deployment 실행 인자에 --kubelet-insecure-tls 를 추가해준다.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: metrics-server
  strategy:
    rollingUpdate:
      maxUnavailable: 0
  template:
    metadata:
      labels:
        k8s-app: metrics-server
    spec:
      containers:
      - args:
        - --cert-dir=/tmp
        - --secure-port=443
        - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
        - --kubelet-use-node-status-port
        - --metric-resolution=15s
        - --kubelet-insecure-tls               <-----------여기 추가
        image: k8s.gcr.io/metrics-server/metrics-server:v0.5.1
        imagePullPolicy: IfNotPresent
        


# 실행 확인


$ kubectl get pods -n kube-system  | grep metric
metrics-server-d69dd899-7ksrz                              1/1     Running   0          11m

$ kubectl logs -f metrics-server-d69dd899-7ksrz -n kube-system
I1014 09:46:17.398903       1 serving.go:325] Generated self-signed cert (/tmp/apiserver.crt, /tmp/apiserver.key)
I1014 09:46:19.086702       1 requestheader_controller.go:169] Starting RequestHeaderAuthRequestController
I1014 09:46:19.086745       1 shared_informer.go:240] Waiting for caches to sync for RequestHeaderAuthRequestController
I1014 09:46:19.086797       1 configmap_cafile_content.go:202] Starting client-ca::kube-system::extension-apiserver-authentication::client-ca-file
I1014 09:46:19.086808       1 shared_informer.go:240] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::client-ca-file
I1014 09:46:19.086836       1 configmap_cafile_content.go:202] Starting client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
I1014 09:46:19.086858       1 shared_informer.go:240] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
I1014 09:46:19.087228       1 dynamic_serving_content.go:130] Starting serving-cert::/tmp/apiserver.crt::/tmp/apiserver.key
I1014 09:46:19.088055       1 secure_serving.go:197] Serving securely on [::]:4443
I1014 09:46:19.088270       1 tlsconfig.go:240] Starting DynamicServingCertificateController
I1014 09:46:19.187012       1 shared_informer.go:247] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::client-ca-file
I1014 09:46:19.187063       1 shared_informer.go:247] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
I1014 09:46:19.187020       1 shared_informer.go:247] Caches are synced for RequestHeaderAuthRequestController

 

kubectl top 동작 확인

$ kubectl top pods
NAME                                              CPU(cores)   MEMORY(bytes)
foo-6579459448-4ddc7                              3m           69Mi
foo-6579459448-4g4mg                              2m           69Mi
foo-6579459448-5pgk2                              2m           68Mi

 

kubectl top 동작 확인 시 아래와 같은 에러가 발생하면 여기 에서 RBAC 을 추가한 이후 다시 확인해보자.

$ kubectl top pod
Error from server (Forbidden): pods.metrics.k8s.io is forbidden: User "front-proxy-client" cannot list resource "pods" in API group "metrics.k8s.io" in the namespace "default"
반응형
Posted by 사용자 guru_k

댓글을 달아 주세요

DB에서 기간별, 날짜별 조회를 해본다.

test DB안에 foo 라는 collection이 아래처럼 존재한다고 할때

mongo> use test;
mongo> db.foo.find().pretty();
{
	"_id" : ObjectId("6154d3d0874aca0169a68c6e"),
	"date" : ISODate("2021-10-01T21:00:00.486Z"),
	"number" : 1
}
{
	"_id" : ObjectId("6154d3d0874aca0169a68c4a"),
	"date" : ISODate("2021-10-02T21:00:00.486Z"),
	"number" : 2
}
{
	"_id" : ObjectId("6154d3d0874aca0169a68a1b"),
	"date" : ISODate("2021-10-03T21:00:00.486Z"),
	"number" : 3
}
{
	"_id" : ObjectId("6154d3d0874aca0169a38p2o"),
	"date" : ISODate("2021-10-04T21:00:00.486Z"),
	"number" : 4
}
{
	"_id" : ObjectId("6154d3d0874aca0169a65d3k"),
	"date" : ISODate("2021-10-05T21:00:00.486Z"),
	"number" : 5
}

특정 기간 (2021/10/01 ~ 2021/10/03) 사이의 데이터를 조회 

mongo> db.foo.find({"date": {$gte: ISODate("2021-10-01T00:00:00.000Z"), $lte: ISODate("2021-10-03T00:00:00.000Z")}})
{
	"_id" : ObjectId("6154d3d0874aca0169a68c6e"),
	"date" : ISODate("2021-10-01T21:00:00.486Z"),
	"number" : 1
}
{
	"_id" : ObjectId("6154d3d0874aca0169a68c4a"),
	"date" : ISODate("2021-10-02T21:00:00.486Z"),
	"number" : 2
}

특정 시간 (2021/10/01 UTC 20:00 ~ 22:00) 사이의 데이터를 조회

mongo> db.foo.find({"date": {$gte: ISODate("2021-10-01T20:00:00.000Z"), $lte: ISODate("2021-10-01T22:00:00.000Z")}})
{
	"_id" : ObjectId("6154d3d0874aca0169a68c6e"),
	"date" : ISODate("2021-10-01T21:00:00.486Z"),
	"number" : 1
}

 

반응형

'Mongo' 카테고리의 다른 글

Mongo 기간별 (날짜별) 조회  (0) 2021.10.13
MongoDB find query by key  (0) 2017.03.02
Posted by 사용자 guru_k

댓글을 달아 주세요

HPA는 Horizontal Pod Autoscaler의 줄임말로 kubernetes 에서 auto scaling을 지원해주는 기능이라고 볼 수 있다.

HPA는 cpu 사용량이나 제공되는 metrics를 기반으로 replication controller, deployment, replica set 또는 stateful set을 scaling 해주는 역할을 수행한다. 단, replicas를 제어할 수 없는 오브젝트 (예로 데몬셋)는 지원되지 않는다.

HPA는 controller manager에 의해서 관리되며 --horizontal-pod-autoscaler-sync-period flag로 설정된 주기마다 컨트롤되는 형태의 컨트롤 루프로 구현된다. (기본 설정은 15초)

위에서 설정된 주기와 HPA 설정에 따라 controller manager는 metrics API로 부터 각 리소스의 metrics 정보를 얻어 온다.

metrics API를 통해 얻어온 metric을 통해 scale 여부를 결정하게 되며 아래와 같은 알고리즘을 통해 desired metric value 와 current metric value의 비율로 결정하게 된다.

desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]

예로 replicas가 1대일 때 current metric value가 200m 이고 desired metric value가 100m 일때 200.0 / 100.0 == 2.0 으로 replicas는 2대로 증설된다.

HPA 연습해보기

시작하기전 HPA는 metrics-server가 제공하는 metric API를 통해서 metrics를 수집하여 scaling을 수행함으로 kubernetes cluster에 metrics-server가 배포 되어있어야 한다. 

테스트를 위한 docker 이미지 생성

부하 생성을 위한 php 파일 생성

<?php
  $x = 0.0001;
  for ($i = 0; $i <= 1000000; $i++) {
    $x += sqrt($x);
  }
  echo "OK!";
?>

Dockerfile 생성

FROM php:5-apache
COPY index.php /var/www/html/index.php
RUN chmod a+rx index.php

Docker build

$ docker build -t hpa-test .
Sending build context to Docker daemon  3.072kB
Step 1/3 : FROM php:5-apache
5-apache: Pulling from library/php
5e6ec7f28fb7: Pull complete
cf165947b5b7: Pull complete
7bd37682846d: Pull complete
99daf8e838e1: Pull complete
ae320713efba: Pull complete
ebcb99c48d8c: Pull complete
9867e71b4ab6: Pull complete
936eb418164a: Pull complete
bc298e7adaf7: Pull complete
ccd61b587bcd: Pull complete
b2d4b347f67c: Pull complete
56e9dde34152: Pull complete
9ad99b17eb78: Pull complete
Digest: sha256:0a40fd273961b99d8afe69a61a68c73c04bc0caa9de384d3b2dd9e7986eec86d
Status: Downloaded newer image for php:5-apache
 ---> 24c791995c1e
Step 2/3 : COPY index.php /var/www/html/index.php
 ---> 767e00d554d2
Step 3/3 : RUN chmod a+rx index.php
 ---> Running in 21c35da0e7dd
Removing intermediate container 21c35da0e7dd
 ---> 89226ef07d25
Successfully built 89226ef07d25
Successfully tagged hpa-test:latest

docker image push

$ docker tag hpa-test docker.hub.io/test/hpa-test

$ docker push docker.hub.io/test/hpa-test
The push refers to repository [docker.hub.io/test/hpa-test]
b08f7a13591f: Pushed
416faf6d334b: Pushed
1aab22401f12: Pushed
13ab94c9aa15: Pushed
588ee8a7eeec: Pushed
bebcda512a6d: Pushed
5ce59bfe8a3a: Pushed
d89c229e40ae: Pushed
9311481e1bdc: Pushed
4dd88f8a7689: Pushed
b1841504f6c8: Pushed
6eb3cfd4ad9e: Pushed
82bded2c3a7c: Pushed
b87a266e6a9c: Pushed
3c816b4ead84: Pushed
latest: digest: sha256:5a8b6cda514a3bd5e90ebf6038180afc7072e5f2c9cc95562949a55d8bca67b2 size: 3449

deployment 및 service 배포

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-apache
spec:
  selector:
    matchLabels:
      run: php-apache
  replicas: 1
  template:
    metadata:
      labels:
        run: php-apache
    spec:
      containers:
      - name: php-apache
        image: hpa-test
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: 500m
          requests:
            cpu: 200m

service.yaml

apiVersion: v1
kind: Service
metadata:
  name: php-apache
  labels:
    run: php-apache
spec:
  ports:
  - port: 80
  selector:
    run: php-apache

배포하기

$ kubectl apply -f deployment.yaml
deployment.apps/php-apache created

$ kubectl apply -f service.yaml
service/php-apache created

HPA 생성

다음 명령어를 사용해서 pod replicas를 1대에서 5대까지 scale 가능한 HPA를 생성한다. cpu 사용량은 70% 이상일 경우 scale out되도록 설정한다.

$ kubectl autoscale deployment php-apache --cpu-percent=70 --min=1 --max=5
horizontalpodautoscaler.autoscaling/php-apache autoscaled

$ kubectl get hpa
NAME                      REFERENCE                            TARGETS                        MINPODS   MAXPODS   REPLICAS   AGE
php-apache                Deployment/php-apache                10%/70%                        1         5         0          6s

부하 생성 (scale out)

busybox 이미지를 사용하여 생성된 service를 통해 pod에 부하를 준다.

kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

HPA가 정상적으로 동작하는지 확인

$ kubectl get hpa

NAME         REFERENCE                     TARGET      MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache/scale   335% / 70%  1         5         1          3m

cpu 사용량이 증가하면서 pod replicas가 5대까지 scale out 되었다. deployment를 통해 확인 해보자.

$ kubectl get deploy php-apache
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
php-apache   5/5     5            5           14m

cpu 사용량이 설정된 70%를 넘어감에 따라 pod이 MAXPODS인 5대까지 증설되었다.

부하 중지 (scale in)

부하 중지 후 서비스가 정상적으로 scale in이 되는지 확인해보자.

기존에 실행했던 부하 생성을 중지하기 위해 <Ctrl> + c 로 이전에 띄웠던 컨테이너를 중지 후 확인을 해본다.

$ kubectl get hpa
NAME                      REFERENCE                            TARGETS                        MINPODS   MAXPODS   REPLICAS   AGE
php-apache                Deployment/php-apache                0%/70%                         1         5         1          10m

deployment도 정상적으로 scale in 되었는지 확인 해본다.

$ kubectl get deploy php-apache
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
php-apache   1/1     1            1           18m

cpu 사용량이 0%로 떨어졌으며 replicas의 개수도 MINPODS에 설정된 개수인 1대로 정상적으로 scale in이 되었다.

반응형
Posted by 사용자 guru_k

댓글을 달아 주세요

Kubernetes Service

Kubernetes 2021. 10. 8. 00:12

Kubernetes Pod은 각각 자신만의 IP를 할당 받으며, Pod의 생명주기는 매우 짧은 편입니다. 즉, Pod는 매우 빈번하게 삭제되거나 생성될 수 있으며 Pod은 생성될 때 IP를 할당 받고 삭제 이후 다시 Pod이 생성될 경우 새로운 IP를 할당 받게 됩니다.

이처럼 Pod의 IP는 빈번하게 변경되므로 stable한 IP가 필요한데 이 역할을 Service가 수행하게 됩니다.

Service Type에는 여러가지가 있지만 기본적인 타입은 고유의 Cluster IP를 가지며 이를 이용해서 Kubernetes 내부 혹은 외부에서 통신이 가능하게 됩니다.  

kubernetes Service는 기본적으로 selector로 선택된 app으로 트래픽을 전달하며 로드밸런싱 역할을 수행합니다.

apiVersion: v1
kind: Service
metadata:
  name: foo-service
spec:
  selector:                  
    app: foo
  ports:
  - port: 5000               
    protocol: TCP
    targetPort: 5000

위와 같이 Service를 생성할 수 있으며 foo-service를 통해 selector로 선택된 foo pod에 접근할 수 있습니다.

Kubernetes Service

foo-service를 생성 시 동일한 이름의 endpoints 가 생성이 되며 이 endpoints에 pod ip가 등록되어지며 새로운 pod이 생성 혹은 삭제 될 때 endpoints에 업데이트 됩니다.

Service Types

ClusterIP

kubernetes service의 default type으로 cluster 내부 ip 를 할당 받으며 cluster 내부에서 해당 service를 통해 pod으로 접근이 가능합니다.

NodePort

각 노드에 Port를 외부로 노출하여 외부로부터 노출된 Port로 접근이 가능하도록 합니다. 

Headless

로드밸런싱이 필요 없거나 싱글 서비스 IP가 필요하지 않을 경우 Headless type으로 Service를 구성할 수 있다. Cluster IP를 가지고 있지 않기 때문에 Headless type으로 설정된 Service를 호출 시 Pod IP를 직접 할당 받게 된다.

반응형

'Kubernetes' 카테고리의 다른 글

Kubernetes metrics-server  (0) 2021.10.14
Kubernetes HPA (Horizontal Pod Autoscaler)  (0) 2021.10.12
Kubernetes Service  (0) 2021.10.08
Kubernetes Components  (0) 2021.10.07
kubernetes를 이용한 cluster 구성 - 3  (0) 2018.03.16
[kubernetes] kubernetes를 이용한 cluster 구성 - 2  (0) 2018.03.10
Posted by 사용자 guru_k

댓글을 달아 주세요

Kubernetes Components

Kubernetes 2021. 10. 7. 00:39

기본적으로 Kubernetes cluster는 node 라고 불리는 일련의 워커 머신들로 이루어져있다. 그 노드 안에서 containerized 된 어플리케이션들이 실행된다.

Kubernetes Cluster

Kubernetes Components 는 크게 두가지로 볼 수 있다.

Control Plane Components 와 Node Components 이며 Control Plane은 클러스터에서 Pod 과 Worker Node들을 관리하는데 Production 환경에서 Control Plane은 fault-tolerance 와 high availability를 위해 여러 머신에 걸쳐 구동 되어진다.

 

Control Plane Components

Control Plane 들은 클러스터 내에서 발생하는 다양한 이벤트들을 결정하는 역할을 수행한다. 예로 새로운 Pod이 생성이 될 경우 어떤 Node에 뜨도록 할것인지에 대한 것을 결정하기도 한다.Control Plane 들은 아무 Node에서나 구동이 될 수 있지만 모든 Components들은 같은 머신에 구동되어지도록 설정하는 것이 좋다. 그리고 대게 Master Node에 구동이 되어지며 User Container들을 Control Plane들이 구동되어지는 Node에 구동하지 않도록 하자.

kube-apiserver

kube-apiserver는 kubernetes API를 노출하고 있는 Component이며 kubernetes control plane의 front end로 볼 수 있다.kube-apiserver의 주요 역할은 kubernetes API를 사용할 수 있도록 하는것이며 kube-apiserver는 수평적 확장이 가능한 구조로 디자인되어있어 여러 인스턴스를 구동하여 트래픽을 조절할 수 있다.

etcd

모든 클러스터의 Kubernetes' backing store 를 저장하는 용도로 사용하는 고가용성 Key Value store로 사용되어 진다.

kube-scheduler

kube-scheduler component 는 지정된 Node가 없는 새로운 Pod이 구동 될 경우 어떤 Node에서 해당 Pod이 구동될것인지에 대한 선택을 하게 된다.

kube-controller-manager

 kube-controller는 아래와 같이 네가지의 분리된 controller process로 구성되어있으나 복잡성을 줄이기 위해 하나의 바이너리로 구동되어진다.

  • Node controller: 노드가 다운되었을 때 대응을 담당
  • Job controller: Job object들을 감지하면서 해당 Job들이 완료될 수 있도록 Pod들을 생성
  • Endpoints controller: Endpoints object 들을 담당. Service와 Pod을 조인
  • Service Account & Token controllers: 새로운 네임스페이스들을 위한 기본 account들과 API access token들을 생성

Node Components

Node Component 들은 모든 Node에서 동작하며, Pod의 구동을 유지하며 kubernetes runtime environment를 제공한다.

kubelet

각 Cluster의 각 Node에서 실행되는 Agent이다. Container들이 Pod안에서 확실히 실행될 수 있도록 관리한다

다양한 메카니즘을 통해 제공된 PodSpecs들을 제공 받아서 PodSpecs에서 서술된 Container들의 running과 healthy를 확실하게 관리한다.

그러나 kubernetes에 의해 만들어지지 않은 container들은 관리하지 않는다.

kube-proxy

kube-proxy는 각 노드에서 kubernetes service concept로 실행되는 network proxy 이다.

kube-proxy는 각 노드에서 네트워크 룰들을 관리하고, 이러한 네트워크 룰들은 클러스터 내외부의 네트워크 세션으로부터 발생하는 커뮤니케이션이 허용되도록 한다.

kube-proxy는 OS Layer의 Packet filtering이 존재하면 그것을 사용하며 없을 경우 트래픽 자체를 포워드 한다.

Container runtime

container runtime은 container들을 실행을 담당하는 소프트웨어이다.

kubernetes는 몇몇의 container runtime들을 지원하며. Docker, containerd, CRI-O 그리고 Kubernetes CRI를 구현한 소프트웨어들이 해당한다.

반응형
Posted by 사용자 guru_k

댓글을 달아 주세요

source code: https://github.com/kgmhk/spring-boot-tutorial/tree/gradlew

gradlew (gradle wrapper) 란

  • gradle wrapper 줄여서 gradlew 는 새로운 환경에서 프로젝트를 설정할 때 java나 gradle을 설치하지 않고 바로 빌드할 수 있게 해주는 역할을 한다.
  • gradlew 를 생성하면 아래와 같은 파일들이 생성된다. (참고 : https://docs.gradle.org/current/userguide/gradle_wrapper.html)
.
├── build.gradle
├── settings.gradle
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew
└── gradlew.bat
  • gradlew 는 shell script 이며 gradlew.bat는 Window batch script 이다.
  • gradlew 를 사용하는 가장 큰 이유는 아래와 같이 로컬환경에서 빌드할 경우 로컬 환경에 설치된 java와 gradle 버전에 영향을 받게 된다.
$ gradle build
  • gradlew 를 이용하여 빌드하면 로컬 환경 java와 gradle 버전과 상관없이 새로운 프로젝트를 빌드할 수 있다.
$ ./gradlew build

 

gradlew 생성하기

  • 프로젝트 초기에 gradlew 생성 시 아래 명령어를 이용하여 gradlew 생성
$ gradle init
  • 이미 로컬 환경에서 build.gradle 를 사용하여 빌드를 진행하고 있던 프로젝트라면 아래 명령어로 gradlew 생성
$ gradle wrapper
> Task :wrapper

BUILD SUCCESSFUL in 0s
1 actionable task: 1 executed

 

gradlew 를 이용한 빌드

  • gradlew 빌드
$ ./gradlew build
  • gradlew 빌드 후 기존 어플리케이션 실행
$ ./gradlew build && java -jar build/libs/helloworld-0.1.0.jar

BUILD SUCCESSFUL in 1s
4 actionable tasks: 4 up-to-date

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::        (v2.1.6.RELEASE)

2019-08-02 09:40:27.901  INFO 54669 --- [           main] hello.Application                        : Starting Application on apseonote344.ad.ea.com with PID 54669 (/Users/gkwak/Documents/spring/helloworld/build/libs/helloworld-0.1.0.jar started by gkwak in /Users/gkwak/Documents/spring/helloworld)
2019-08-02 09:40:27.904  INFO 54669 --- [           main] hello.Application                        : No active profile set, falling back to default profiles: default
2019-08-02 09:40:28.927  INFO 54669 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8080 (http)
2019-08-02 09:40:28.957  INFO 54669 --- [           main] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
2019-08-02 09:40:28.957  INFO 54669 --- [           main] org.apache.catalina.core.StandardEngine  : Starting Servlet engine: [Apache Tomcat/9.0.21]
2019-08-02 09:40:29.046  INFO 54669 --- [           main] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext
2019-08-02 09:40:29.046  INFO 54669 --- [           main] o.s.web.context.ContextLoader            : Root WebApplicationContext: initialization completed in 1092 ms
2019-08-02 09:40:29.241  INFO 54669 --- [           main] o.s.s.concurrent.ThreadPoolTaskExecutor  : Initializing ExecutorService 'applicationTaskExecutor'
2019-08-02 09:40:29.447  INFO 54669 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http) with context path ''
2019-08-02 09:40:29.452  INFO 54669 --- [           main] hello.Application                        : Started Application in 1.956 seconds (JVM running for 2.353)

 

 

반응형
Posted by 사용자 guru_k

댓글을 달아 주세요