Skip to content

태그: Kubernetes

GoCD는 CI/CD(지속적 배포-Continuous Delivery) 파이프라인을 쉽게 모델링 및 시각화할 수 있도록 해주는 툴이다. 젠킨스처럼 다양한 플러그인을 지원하지는 않지만, 파이프라인 요청에 따라 클러스터에서 적절한 리소스를 할당해 실해주는 Ad-Hoc 환경을 지원해주기 때문에 클라우드 환경에 좀더 적합할 수 있다. 실습 설치 helm으로 빠르게 깔아보자 helm repo add gocd repo updatehelm install gocd gocd/gocd --namespace gocd --create-namespace 파이프라인 수정 처음 들어가면 getting_started_pipeline이 보인다. GoCD의 파이프라인은

MetalLB는 BareMetal LoadBalancer의 약자로, Kubernetes 클러스터에 연결되어 온프레미스 환경(IDC)에서 로드밸런서 타입 서비스를 구현해주는 툴이다. MetalLB가 제공하는 기능을 크게 나누면 주소를 할당해주는 기능과 외부와 연결하는 기능 두 가지로 나누어 볼 수 있다. 주소 할당 클라우드 제공업체의 Kubernetes 클러스터에서는 로드밸런서를 요청하면 클라우드 플랫폼이 IP 주소를 할당해준다. 베어메탈 클러스터에서는 MetalLB가 이 할당을 담당한다. MetalLB에 사용할 수 있는 IP 주소 풀을 제공하면 해당 풀에서 LB를 생성해준다. 외부 연결 MetalLB가 서비스에 외부 IP 주소를 할당한 후에는 해당 IP가 클러스터에 “존재한다”는 것을 클러스터 외부

Metrics Server is a scalable, efficient source of container resource metrics for Kubernetes built-in autoscaling pipelines. K8s 메트릭 API(Metrics API) 는 자동 스케일링 및 비슷한 사용 사례를 지원하기 위한 기본적인 메트릭 집합을 제공한다. 이 API를 사용해 노드와 파드의 CPU 및 메모리 사용량을 쉽게 쿼리할 수 있다. (kubectl top HorizontalPodAutoscaler(HPA) 와 VerticalPodAutoscaler(

AWS Load Balancer Controller

AWS Load Balancer Controller is a controller to help manage Elastic Load Balancers for a Kubernetes cluster. It satisfies Kubernetes Ingress resources by provisioning Application Load Balancers. It satisfies Kubernetes Service resources by provisioning Network Load Balancers. This project was formerly known as “AWS ALB Ingress Controller”, we rebranded it to be “AWS Load Balancer Controller”. De

Add IAM to RBAC

Add new IAM user or role to the Kubernetes RBAC, using kubectl or eksctl Before you choose the kubectl or eksctl tool to edit the aws-auth ConfigMap, make sure that you complete step 1. Then, follow steps 2-4 to edit with kubectl. To edit with eksctl, proceed to step 5. After you identify the cluster creator or admin, configure AWS CLI to use the cluster creator IAM. See Configuration basics for

The AWS-provided VPC CNI is the default networking add-on that runs on Kubernetes worker nodes for EKS clusters. VPC CNI add-on is installed by default when you provision EKS clusters. The VPC CNI provides configuration options for pre-allocation of ENIs and IP addresses for fast Pod startup times.\ VPC CNI components Amazon VPC CNI has two components: CNI Binary: which will setup Pod netwo

If you want to persist your own data to EBS in EKS environment, you can use EBS CSI driver addon provided by AWS. Beforehand we need to enable the IAM OIDC provider and create the IAM role for the EBS CSI driver. The easiest way to do both is to use eksctl (other ways like using plain aws cli or the AWS GUI are described in the docs). 1. Enable IAM OIDC provider A prerequisite for the EBS CSI driv

When you create a Kubernetes ingress, an AWS Application Load Balancer (ALB) is provisioned that load balances application traffic. ALBs can be used with Pods that are deployed to nodes or to AWS Fargate. You can deploy an ALB to public or private subnets. Before you can load balance application traffic to an application, you must meet the following requirements. Prerequisites Have an existing c

EKS Control Plane

EKS is a managed Kubernetes service that mekes it easy for you to run Kubernetes on AWS without needing to install, operate, and main your own Kubernetes control plane or worker nodes. It runs ipstream Kubernetes and is certified Kubernetes conformant. EKS automatically manages the availability and scalability of the Kubernetes control plane nodes, and it automatically replaces unhealthy control p

EKS Network BestPractice

It is critical to understand Kubernetes networking to operate you cluster and applications efficiently. Pod networkin, also called the cluster networking, is the center of Kubernetes networkin. Kubernetes supports Container Network Interface(CNI) plugins for cluster networking. Amazon EKS officially supports VPC CNI plugin to implement Kubernetes Pod networking. The VPC CNI provides native integra

EKS Spot Instances with Karpenter

Karpenter is a dynamic, high performance cluster auto scaling solution for the Kubernetes platform. Customers choose an auto scaling solution for a number of reasons, including improving the high availability and reliability of their workloads at the same reduced costs. With the introduction of Amazon EC2 Spot Instances, customers can reduce costs up to 90% compared to On-Demand prices. Combining

EKS 기본 환경 Setting 방법을 알아보자. 쿠버네티스는 kubectl에 대한 인증정보를 kubeconfig라는 yaml파일에 저장한다. EKS 클러스터는 어떻게 접근을 하는지, 어떻게 인증을 받아오는지 알아보자. Kubeconfig EKS 클러스터에 접근 가능한 kubeconfig파일을 생성하는 것은 간단하다. aws command 한 줄이면 인증 정보를 kubeconfig 파일에 저장할 수 있다. Terminal windowaws eks --region &x3C;region-code> update-kubeconfig --name &x3C;cluster_name> update-kubeconfig --name "> kubeconfig 파일 내용을 살펴보자. apiVersion: v1clusters:cl

EKS 인증과정

kubectl에서 EKS Cluster의 K8s API Server에 접근하거나, Worker Node에서 동작하는 kubelet에서 EKS Cluster의 K8s API Server 접근시에는 AWS IAM Authenticator가 이용된다. 왼쪽은 kubelet의 kubeconfig이고, 오른쪽은 kubectl의 kubeconfig이다. 두 kubeconfig 모두 user 부분을 확인해보면 aws eks get-token 명령어를 수행하는 것을 확인할 수 있다. aws eks get-token 명령어는 해당 명령어를 수행하는 Identity가 누구인지 알려주는 AWS STS의 GetCallerIdentity API의 Presigned URL을 생성하고, 생성한 URL을 Encoding하여 Tok

IP addresse prefix

Each Amazon EC2 instance supports a maximum number of elastic network interfaces and a maximum number of IP addresses that can be assigned to each network interface. Each node requires one IP address for each network interface. All other available IP addresses can be assigned to Pods. Each Pod requires its own IP address. As a result, you might have nodes that have available compute and memory res

AWS Load Balancer Controller supports Network Load Balancer (NLB) with IP tergets for pods runing on Amazon EC2 instances and AWS Fargate through Kubernetes service of type LoadBalancer with proper annotation. In this mode, the AWS NLB targets traffic directly to the Kubernetes pods behind the service, aliminationg the need for an extra network hop through the worker nodes in the Kubernetes cluste

A Kubernetes node is a physical or virtual machine participating in a Kubernetes cluster, which can e used to run pods. When a node shuts down or crashed, it enters the NotReasy state, meaning it cannot be used to run pods. All stateful pods running on the node then becom unavailable. Common reasons for a Kubernetes node not ready error include lack of resources on the node, a problem with the kub

K8s Architecture

쿠버네티스는 중앙(Master)에 API 서버와 상태 저장소를 두고 각 서버(Node)의 에이전트(kubelet)와 통신하는구조로 동작한다. 하지만 이 개념을 여러 모듈로 쪼개어 구현하고 다양한 오픈소스를 사용하기 떄문에 설치가 까다롭고 구성이 복잡해보일 수 있다. 마스터-노드 구조 쿠버네티스는 전체 클러스터를 관리하는 마스터와 컨테이너가 배포되는 노드로 구성되어있다. 모든 명령은 마스터의 API 서버를 호출하고 노드는 마스터와 통신하면서 필요한 작업을 수행한다. 특정 노드의 컨테이너에 명령하거나 로그를 조회할 때도 노드에 직접 명령하는게 아니라 마스터에 명령을 내리고 마스터가 노드에 접속하여 대신 결과를 응답한다. Master 마스터 서버는 다양한 모듈이 확장성을 고려하여 기능별로 쪼개져 있는 것이 특징이

쿠버네티스(Kubernetes)는 컨테이너화 된 애플리케이션의 대규모 배포, 스케일링 및 관리를 간편하게 만들어주는 오픈 소스 기반 컨테이너 오케스트레이션 도구이다. 프로덕션 환경에서는 애플리케이션을 실행하는 여러 컨테이너를 관리하고 다운타임이 없는지 확인해야하는데, Kubernetes는 다중 컨테이너 처리를 자동으로 처리하고, 분산 시스템을 탄력적으로 실행할 수 있는 프레임워크를 제공한다. K8s를 사용하면 애플리케이션의 확장 및 장애 조치를 처리하고 배포 패턴 등을 쉽게 처리할 수 있다. 쿠버네티스의 특징 5가지 1. 선언적 접근 방식 쿠버네티스에서는 동작을 지시하는 개념보다는 상태를 선언하는 개념을 주로 사용한다. 쿠버네티스는 원하는 상태(Desired state)와 현재의 상태(Current sta

Kubernetes Overview Diagrams

CoreDNS는 일반적으로 Kubernetes Cluster 내부에서 이용되는 DNS Server이다. Kubernetes Cluster 내부에서 Domain을 통해서 Service나 Pod의 IP를 찾기 위한 용도로 많이 이용된다. CoreDNS는 일반적으로 Worker Node에서 Deployment로 배포되어 다수의 Pod으로 구동된다. 그리고 다수의 CoreDNS Pod들은 CoreDNS Service를 통해서 VIP (ClusterIP)로 묶이게 된다. Kubernetes Cluster의 Pod들은 CoreDNS Service의 VIP를 통해서 CoreDNS에 접근하게 된다. 다수의 CoreDNS Pod와 CoreDNS Service를 이용하는 이유는 HA(High Availability) 때문이다

두개의 포드와 서비스가 있다고 해보자. 각 포드의 이름은 test와 web이고, 가상 IP를 하나씩 할당받았다. /-----\ /-------- /-----\ | pod | 《 service | pod | \-----/ \-------- \-----/ 10.244.1.5 10.107.37.188 10.244.1.5 test web-service web 서비스가 생성되면, k8s DNS sevice(CoreDNS)는 해당 서비스를 위한 레코드를 저장한다. 즉, ip를 직접 명시하지 않고 사용할 수 있는 대체 이름을 지정해준다는 것이다. 우선 클러스터 내부에서 포드는

ExternalDNS는 kubernetes dns(kube-dns)와 상반되는 개념으로 내부 도메인서버가 아닌 Public한 도메인서버(AWS Route53, GCP DNS 등)를 사용하여 쿠버네티스의 리소스를 쿼리할 수 있게 해주는 오픈소스 솔루션이다. ExternalDNS를 사용하면 public도메인 서버가 무엇이든 상관없이 쿠버네티스 리소스를 통해서 DNS레코드를 동적으로 관리 할 수 있다. ExternalDNS 설치 쿠버네티스 서비스 계정에 IAM 역할을 사용하려면 OIDC 공급자가 필요하다. IAM OIDC 자격 증명 공급자를 생성한다. Terminal windoweksctl utils associate-iam-oidc-provider --cluster {cluster name} --approve

생성된 서비스의 IP는 어떻게 알 수 있을까? 서비스가 생성된 후 kubectl get svc를 이용하면 생성된 서비스와 IP를 받아올 수 있지만, 이는 서비스가 생성된 후이고, 계속해서 변경되는 임시 IP이다. DNS를 이용하는 방법 가장 쉬운 방법으로는 DNS 이름을 사용하는 방법이 있다. 서비스는 생성되면 [서비스 명].[네임스페이스명].svc.cluster.local 이라는 DNS 명으로 쿠버네티스 내부 DNS에 등록이 된다. 쿠버네티스 클러스터 내부에서는 이 DNS 명으로 서비스에 접근이 가능한데, 이때 DNS에서 리턴해주는 IP는 외부 IP (External IP)가 아니라 Cluster IP (내부 IP)이다. 간단한 테스트를 해보자. hello-node-svc 가 생성이 되었는데, 클러스터내의

Debugging DNS Resolution

You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. Create a simple Pod to use as a test environment apiVersion: v1kind: Podmetadata: name: dnsutils namespace: defaultspec: containers: name: dnsutils

The Ingress object was added to Kubernetes in version 1.1 to describe properties of a cluster-wide reverse HTTP proxy. Since that time, the Ingress API has remained relatively unchanged, and the need to express implementation-specific capabilities has inspired an explosion of annotations. The goal of the HTTPProxy Custom Resource Definition (CRD) is to expand upon the functionality of the Ingress

IP Virtual Server (IPVS) is a Linux connection (L4) load balancer. iptables can do simple L4 load balancing by randomly routing connections, with the randomness shaped by the weights on individual DNAT rules. IPVS supports multiple load balancing modes (in contrast with the iptables one), which are outlined in below Table. This allows IPVS to spread load more effectively than iptables, depending

Kubernetes’s default befavior is to allow traffic between any two pods in the cluster network. This behavior is a deliberate design choice for ease of adoption and flexibility of configuration, but it is highly undesirable in practice. Allowing any system to make (or receive) arbitrary connections creates risk. An attacker can probe systems and can porentially exploit captured credentials to find

Network Troubleshooting

Troubleshooting network0related issues with Linux is a complex topic and could easily fill its own book. we will introduce some key troubleshooting tools and the basics of their use. There is substantial overlap in the tools that we describe, so you may find learning about some tools (or tool features) redundant. Some are better suited to a given task than others (for example, multiple tools will

Node and Pod Network Layout

The cluster must have a group of IP addresses that is controls to assign an IP address to a pod, for example, 10.1.0.0./16. Nodes and pods must have L3 conectivity in this IP address space. In L3, ths Internet layer, connectivity means packets with an IP address can route to a host with that IP address. It is important to note that the ability to deliver packets is more fundamental than creati

eBPF is a programming system that allows special sandboxed programs to run in the kernel without passing back and forth between kernel and user space, like we saw with Netfilter and iptables. Before eBPF, there was the Berkeley Packet Filter (BPF). BPF is a technology used in the kernel, among other things, to analyze network traffic. BPF supports filtering packets, which allows a userspace proces

A dry run (or practice run) is a software testing process used to make sure that a system works correctly and will not result in severe failure. Istio has a experimental annotation istio.io/dry-run to dry-run the policy without actually enforcing it. The dry-run annotation allows you to better understand the effect of an authorization policy before applying it to the production traffic. This helps

Terminal windowistioctl proxy-statusNAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSIONargocd-application-controller-0.argocd Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-977466b69-2kms7 1.18.2argocd-applicationset-contr

Istio Arcitecture

An Istio service mesh is logically split into a data plane and a control plane. The data plane is composed of a set of intelligent proxies (Envoy) deployed as sidecars. These proxies mediate and control all network communication between microservices. They also collect and report telemetry on all mesh traffic. The control plane manages and configures the proxies to route traffic. The followi

Istio Configuration Profiles

default: enables components according to the default settings of the IstioOperator API. This profile is recommended for production deployments and for primary clusters in a multicluster mesh. You can display the default settings by running the istioctl profile dump command. demo: configuration designed to showcase Istio functionality with modest resource requirements. It is suitable to run the

Istio RBAC를 통해 네임스페이스, 서비스, HTTP 메소드 수준의 권한 제어를 실습 해보자. 준비작업 k8s, helm 설치 Istio 초기화 (namespace, CRDs) Terminal window$ wget tar -vxzf istio-1.8.2-osx.tar.gz$ cd istio-1.8.2$ kubectl create namespace istio-system$ helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl appl

Istio authorization

Istio는 ClusterRbacConfig를 통해 ServiceRole에 권한 Rule을 정의한 후 ServiceRoleBinding을 통해 특정 대상에 해당 ServiceRole에 지정하여 접근 제어를 수행한다. mesh, namespace, workload 범위에서의 access control을 적용할 수 있다. Istio authorization을 사용했을 때 얻을 수 있는 이점은 아래와 같다. 간단한 API: AuthorizationPolicy CRD를 통해 쉬운 접근 제어가 가능하다. 유연한 설정: CUSTOM, DENY 및 ALLOW 등 Istio 특성에 대한 사용자 지정 조건을 자유롭게 정의할 수 있다. 고성능: Envoy native를 사용하기에 성능이 우수하다. 높은 호환성: gRPC,

Resource Annotations & Labels

The various resource annotations that Istio supports to control its behavior.

Since not all services live in the sevice mesh, we need a way for services inside the mesh to communicate with those outdise the mesh. Those could be existing HTTP services or, more likely, infrastructure services like databases or caches. We can still implement sophisticated routing for services that reside outside Istio, but first we have to introduce the concept of a ServiceEntry. Istio builds

gateway log debug 하는 법

Debugging Istio Envoy filters can be challenging but there are several techniques and tools that can help you troubleshoot issues. Here’s a step-by-step guide to debug Istio Envoy filters: 1. Enable Debug Logs: By default, Istio’s Envoy sidecar logs only contain essential information. To get more detailed logs, you can enable debug logging by changing the log level. To do this, you’ll need to modi

ApplicationSets

Applications deployed and managed using the GitOps philosophy are often made of many files. There’s Kubernetes manifests for Deployments, Services, Secrets, ConfigMaps, and many more which all go into a Git repository to be revision controlled. Argo CD, the engine behind the OpenShift GitOps Operator, then uses that Git repository as the source for the application. So, how do we define all that to

ArgoCD application을 모아서 관리하는 패턴을 App of Apps 패턴이라고 한다. app of app 패턴으로 구성된 application을 sync하면 여러 argoCD application을 생성하고, 생성된 application은 바라보는 git에 저장된 쿠버네티스 리소스를 배포한다. 상위 앱이 하위 앱을 여러개 정의하는 구조라고 보면 된다. 공식 레포에 있는 예제를 살펴보자. ( ├── Chart.yaml├── templates│ ├── guestbook.yaml│ ├── helm-dependency.yaml│ ├── helm-guestbook.yaml│

출처: ArhoCD, ArgCD CLI 설치 Argo CD를 kubernetes cluster에 설치한다. $ kubectl create namespace argocd$ kubectl apply -n argocd -f Argo CD의 CLI를 설치한다. $ curl -sSL -o ~/bin/argocd chmod +

Config Management Plugins

Argo CD allows us to integrate more config management tools using config management plugins. Most prominent inbuilt tools are helm and kustomize. We have to option, when it comes to create our own Config Management Plugin (CMP): Add the plugin config to the main Argo CD ConfigMap. Our repo-server container will then run the plugin’s commands. There are two ways to install a Config Management Plu

Here are some common indicators and states you might encounter while working with ArgoCD: Application States: Healthy: The application is in the desired state and all resources are successfully deployed and reconciled. OutOfSync: The application’s current state does not match the desired state defined in the Git repository. This can happen if there are differences in resource definitions or con

Let’s deploy Cilium for testing with our Golang web server in below example. We will need a Kubernetes cluster for deploying Cilium. One of the easiest ways we have found to deploy clusters for testing locally is KIND, which stands for Kubernetes in Docker. It will allow us to create a cluster with a YAML configuration file and then, using Helm, deploy Cilium to that cluster. KIND configuration fo

Karpenter is an open-source, flexible, high-performance Kubernetes cluster autoscaler built with AWS. It helps improve your application availability and cluster efficiency by rapidly launching right-sized compute resources in response to changing application load. Karpenter also provides just-in-time compute resources to meet your application’s needs and will soon automatically optimize a cluster’

Karpenter best practices

Use Karpenter for workloads with changing capacity needs karpenter brings scailing management closer to Kubernetes native APIs than do Autoscaling Groups (ASGs) and Managed Node Groups (MNGs). ASGs and MNGs are AWS-native abstractions where scaling is triggered based on AWS level metrics, such as EC2 CPU load. Cluster Autoscaler bridges the Kubernetes abstractions into AWS abstractions, but loses

Kyverno(Greek for “govern”) is a policy engine designed for Kubernetes. It can validate, mutate, and generate configurations using admission controls and background scans, Kyverno policies are Kubernetes resources and do not require learning new language. Kyverno is designed to work nicely with tools you already use like kubectl, kustomize, and Git. Featchers Kyverno is a policy engine designed sp

Kyverno is a Kubernetes native policy engine that helps in enforcing custom policies on Kubernetes objects. It is a highly scalable and declarative tool that allows Kubernetes administrators to enforce security, compliance, and operational policies across their clusters. Kyverno policies are written in YAML format and can be defined as cluster-wide resources (using the kind ClusterPolicy) or names

K8s에서 LB를 사용하기 위해선 AWS, GCP, Azure 등 플랫폼에서 제공해주는 서비스를 사용해야하고, 온프레미스 클러스터에서는 추가 모듈 설치가 필요하다. MetalLB는 BareMetal Loadbalancer의 약자로, 베어메탈 환경에서 사용할 수 있는 로드밸런서를 제공하는 오픈소스 프로젝트이다. MetalLB의 동작에는 두가지 방식이 있다. 1. L2 Mode L2 모드는 2계층 통신을 이용한다. 각 노드마다 speaker라는 데몬셋이 생성되고, 호스트 네트워크를 사용한다. 리더 speaker pod를 선출한다. 리더는 ARP(GARP)로 해당 External IP에 대한 소유를 주장한다. arpping을 이용하여 어떤 Speaker pod가 external IP를 관리하는지 직접 찾을

Node Termination Handler

Node Termination Handler는 EC2 인스턴스가 EC2 maintenance events, EC2 Spot interruptions, ASG Scale-In, ASG AZ 재조정, and EC2 Instance Termination 등의 이유로 사용할 수 없는 상태가 되었을 때 대응하기 위한 tool이다. 그에 대한 핸들링을 제때 해줌으로써 Pod를 더 빠르게 회복시키고 availability를 높일 수 있다. modes The aws-node-termination-handler(NTH)에는 Instance Metadata Service (IMDS) 모드와 Queue Processor 모드 두가지가 있다. IMDS mode The aws-node-termination-handler Insta

The Open Policy Agent Gatekeeper project can be laveraged to help enforce policies and strengthen governence in your Kubernetes environment. If your organization has been operating Kubernetes, you probably have been looking for ways to control what end-users can do on the cluster and ways to ensure that clusters are in compliance with company policies. These policies may be there to meet governanc

Chart Development Tips

Template Functions Helm uses Go templates for templating your resource files. While Go ships several built-in functions, we have added many others. First, we added all of the functions in the Sprig library, except env and expandenv, for security reasons. We also added two special template functions: include and required. The include function allows you to bring in another template, and then pass t

Helm이란, kubernetes 패키지 관리를 도와주는 tool이다. Node.js의 npm, Python의 pip와 같은 역할이라고 볼 수 있다. Chart Helm은 차트라고 불리는 Package formet을 사용한다. 차트는 Kubernetes Resouce들의 내용을 나타내는 파일들의 집합이다. 예를 들어 Wordpress의 차트는 아래와 같은 구조를 가지고있다. Terminal windowwordpress/ Chart.yaml chart에 대한 정보 LICENSE (선택사항) chart의 license에 대한 정보 README.md (선택사항) 사람이 읽을 수 있는 README 파

Values is One of the built-in objects. This object provides access to values passed into the chart. Its contents come from multiple sources: The values.yaml file in the chart If this is a subchart, the values.yaml file of a parent chart A values file if passed into helm install or helm upgrade with the -f flag (helm install -f myvals.yaml ./mychart) Individual parameters passed with --set (such a

kubernetes node에 쉽게 접속할 수 있도록 하는 kubectl 플러그인이다. 워커노드, 인그레스노드에 접근이 가능하고 root 권한으로 실행이 가능하다. krew 설치하기 node-shell는 krew를 통해 설치할 수 있다. Terminal window krew 설치하기$ brew install krew krew에 kvaps 추가$ kubectl krew index add kvaps node-shell 설치하기 Terminal window node-shell을 설치한다.$ kubectl krew install kvaps/node-shell export 추가하기 Terminal window vi 편집기 사용하여 ~/.zshrc or

CNI Specification

The CNI specification itself is quite simple. According to the specification, there are four operations that a CNI plugin must support: ADD: Add a container to the network. DEL: Delete a container from the network. CHECK: Return an error if there is a problem with the container’s network. VERSION: Report version information about the plugin. The full CNI spec is available on GitHub In above

Disruption Budget

Let’s explore to limit the number of concurrent disruptions that your application experiences, allowing for higher availability while permitting the cluster administrator to manage the clusters nodes. The most common use case when you want to protect an application specified by one of the build-in Kubernetes controllers: Deployment ReplicationController ReplicaSet StatefulSet In this case, make

쿠버네티스의 Services는 뒷단에 있는 Pod의 label 정보를 바탕으로한 selector로 그 대상이 되는 Pod를 매칭한다. 만약 해당 Label을 단 새로운 Pod이 생겼다면, Service는 자동으로 그 Pod과 연결되어 트래픽을 보낸다. 이러한 일이 가능한 것은 service가 트래픽을 보낼 오브젝트를 추적해주는 EndPoint가 있기 때문이다. 매칭된 Pod의 IP 주소는 그 service의 endpoint가 되어 연결된다. service는 endpoints를 통해 트래픽을 보내는 주소의 목록을 관리한다. endpoints는 labels와 selectors를 통해 자동으로 업데이트 될 수 있다. 그리고 경우에 따라 수동으로 endpoints를 설정할 수 있다. service selec

HPA(Horizontal Pod Autoscaler) Horizontal Pod Autoscaler는 metric server를 통해 파드의 리소스를 감시하여 리소스가 부족한 경우 Controller의 replicas를 증가시켜 파드의 수를 늘린다. 위의 그림 처럼 Pod가 수평적으로 증가하는 것을 Scale Out, 수평적으로 감소하는 것을 Scale In 이라고 한다. Pod를 증가시키기 때문에 기존의 트래픽이 분산되어 서비스를 더 안정적으로 유지할 수 있게 된다. Replica의 수와 상관 없이 돌아갈 수 있는 Stateless 서비스에 적합하다. 트래픽이 급증하여 spike가 생기는 경우에 대응할 수 있다. 사용하는 매트릭과, 목표하는 매트릭을 계산하여 desire repli

K8s의 도커런타임 사용중단

Source : 쿠버네티스는 버전 v1.20 이후 Docker를 컨테이너 런타임으로서 사용하지 않겠다고 알렸다.(2020.12.02) GKE 및 EKS 등의 관리 Kubernetes 서비스를 사용하는 경우 오퍼레이터에서 지원되는 버전의 런타임을 사용하는 것을 확인하고 쿠버네티스 릴리스에서 도커 지원이 만료되기 전에 변경 해야한다. 자세한 내용은 아래와 같다. DeprecationDocker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a modul

Networking is a crucial part of Kubernetes. Behind the Kubernetes network, there is a component that work under the hood. It trandlates your Services into some usable networkign rules. This componenet is called Kube-Proxy. kube-proxy is another per-node daemon in Kubernetes, like Kubelet. kube-proxy provides basic load balancing functionality within the cluster. It implements services and relies o

NodePort와 ServicePort와 targetPort

K8s의 포트는 노드와 서비스, 컨테이너별로 나뉘어있다. 이 개념에 대해 확실히 알아보자. 만약에 하나의 서비스에 2개의 노드가 있고, 그 노드에 각각 하나의 포드가 있다고 하면 아래 그림과 같은 모양이 된다. NodePort는 각 노드의 클러스터 레벨에서 노출되는 포트, (그림에서 30001) Port는 서비스의 포트, (80) targetPort는 포드에서 컨테이너로 가는 앱 컨테이너 포트를 말한다. 아래와 같이 설정할 수 있다. ports: protocol: TCP port: 80 targetPort: 8080 nodePort: 30000

Assigning Pods to Nodes

You can constrain a Pod so that it is restricted to run on particular node(s), or to prefer to run on particular nodes. There are several ways to do this and the recommended approaches all use label selectors to facilitate the selection. Often, you do not need to set any such constraints; the scheduler will automatically do a reasonable placement (for example, spreading your Pods across nodes so a

Taints and Tolerations

Node affinity is a property of Pods that attracts them to a set of nodes (either as a preference or a hard requirement) Taints are the opposite — they allow a node to repel a set of pods. Tolerations are applied to pods. Tolerations allow the scheduler to schedule pods with matching taints. Tolerations allow scheduling but don’t guarantee scheduling: the scheduler also evaluates other parameters a

쿠버네티스 클러스터를 사용하다 보면 특정 노드에 있는 포드들을 모두 다른 곳으로 옮기거나 아니면 특정 노드에는 포드들이 스케쥴링 되지 않도록 제한을 걸어야 할 때가 있다. 이러한 기능들을 제공하는 kubectl 명령어가 cordon, drain, taint 등이다. cordon kubectl cordon은 지정된 노드에 더이상 포드들이 스케쥴링되서 실행되지 않도록 한다. kubectl get nodes로 노드 이름을 확인한 다음에 cordon을 해보자. cordon을 한 다음에 다시 노드를 확인해 보면 노드의 status에 SchedulingDisabled라는 STATUS가 추가된 걸 확인할 수 있다. Terminal window$ kubectl get nodesNAME STAT

CSIDriver captures information about a Container Storage Interface (CSI) volume driver deployed on the cluster. Kubernetes attach detach controller uses this object to determine whether attach is required. Kubelet uses this object to determine whether pod information needs to be passed on mount. CSIDriver objects are non-namespaced. The CSIDriver Kubernetes API object serves two purposes: Simplif

attachdetach controller

Objective Make volume attachment and detachment independent of any single node’s availability If a node or kubelet goes down, the volumes attached to that node should be detached so that they are free to be attached to other nodes. Secure Cloud Provider Credentials Because each kubelet is responsible for triggering attach/detach logic, every node currently needs (often broad) permissions. The

A workload is an application running on Kubernetes. Whether your workload is a single component or several that work together, on Kubernetes you run it inside a set of pods. In Kubernetes, a Pod represents a set of running containers on your cluster. Kubernetes pods have a defined lifecycle. For example, once a pod is running in your cluster then a critical fault on the node where that pod is runn

etcd는 key:value 형태의 데이터를 저장하는 스토리지이다. Kubernetes는 기반 스토리지(backing storage)로 etcd를 사용하고 있고, 모든 데이터를 etcd에 보관한다. 클러스터에 어떤 노드가 몇 개나 있고 어떤 파드가 어떤 노드에서 동작하고 있는지 등의 정보가 etcd에 저장되는 것이다. RSM(Replicated state machine) etcd는 분산 컴퓨팅 환경에서 서버가 몇 개 다운되더라도 정상적으로 동작하는 Replicated state machine(RSM)방식으로 구현되었다. RSM은 위 그림과 같이 command가 들어있는 log 단위로 데이터를 처리한다. 데이터를 write하는 것을 log append라고 부르고, 머신은 받은 log를 순서대로 처리하는

You can use Kubernetes annotations to attach arbitrary non-identifying metadata to objects. Clients such as tools and libraries can retrieve this metadata. You can use either labels or annotations to attach metadata to Kubernetes objects. Labels can be used to select objects and to find collections of objects that satisfy certain conditions. In contrast, annotations are not used to identify

Custom resources are extensions of the Kubernetes API. This page discusses when to add a custom resource to your Kubernetes cluster and when to use a standalone service. It describes the two methods for adding custom resources and how to choose between them. Custom resources A resource is an endpoint in the Kubernetes API that stores a collection of API objects of a certain kind; for example, the

Deplotment는 Pod와 ReplicaSets를 위한 선언적 업데이트를 제공한다. Deployment는 k8s의 핵심 개념중 하나인 desired state(목표 상태)를 설명하는 요소이다. Deployment에서 desired state를 정의하면 배포 컨트롤러가 원하는 상태로 복구한다. Deploy를 만들어 실습해보자! 더 자세하고 정확한 설명은 공식 를 참고하자. Creating a Deployment apiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deployment labels: app: nginxspec: replicas: 3 selector: matchLabels: app: nginx template:

Deployment Status

A Deployment enters various states during its lifecycle. It can be progressing while rolling out a new ReplicaSet, it can be complate, or it can fail to progress. Progressing Deployment Kubernetes marks a Deployment as progressing when one of the follwing tasks is performed: The Deployment creates a new ReplicaSet. The Deployment is scaling up its newest ReplicaSet. The Deployment is scaling down

Deployment Strategy

Deployment’s .spec.strategy specifies the strategy used to replace old Pods by new ones. .spec.strategy.type can be “Recreate” or “RollingUpdate”. “RollingUpdate” is the default value. Recreate Deployment All existing Pods are killed before new ones are created when .spec.strategy.type==Recreate. Note: This will only guarantee Pod termination previous to creation for upgrades. If you upgrade a D

Kubernetes Events는 하나의 Kubernetes 리소스 타입으로서 Kubernetes 리소스들의 state 변화, 에러 또는 시스템에 특정 메세지를 전파해야할 때 자동으로 만들어진다. 이러한 Kubernetes Events 리소스는 Kubernetes 개발 및 운영하며 디버깅시에 매우 유용하게 사용된다. Events 조회 kubectl describe pod pod-name를 사용하면 아랫부분에 Events 항목을 볼 수 있다. 이것이 바로 해당 Pod와 관련된 Kubernetes Events들의 정보를 나타낸다. 특정 Pod 뿐 아니라 현재 namespace 에 발생하는 모든 Events를 조회하고 싶다면 kubectl get events 를 통해 조회할 수 있다. 하지만 모든 리소스들의 E

Labels and Selectors

Labels are key/value pairs that are attached to objects such as Pods. Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system. Labels can be used to organize and to select subsets of objects. Labels can be attached to objects at creation time and subsequently added and modi

k8s에서 Volume을 사용하는 구조는 PV라고 하는 퍼시스턴트 볼륨(PersistentVolume)과 PVC라고 하는 퍼시스턴트 볼륨 클레임(PersistentVolumeClaim) 2개로 분리되어 있다. PV/PVC PV는 Persistent Volume의 약자이다. pod와는 별개로 관리되며 별도의 생명 주기가 있다. PVC는 사용자가 PV에 하는 요청이다. 사용하고 싶은 용량은 얼마인지, 읽기/쓰기는 어떤 모드로 설정하고 싶은지 등을 정해서 요청한다. k8s 볼륨을 pod에 직접 할당하는 방식이 아니라 중간에 PVC를 두어 pod와 pod가 사용할 스토리지를 분리할 수 있다. 이런 구조는 pod 각각의 상황에 맞게 다양한 스토리지를 사용할 수 있게 한다. 클라우드 서비스를 사용할 때는 본인이 사용

Pod는 동일한 실행환경에서 실행되는 애플리케이션 컨테이너와 볼륨으로 구성된 집합체다. 포드는 쿠버네티스 클러스터에서 배포 가능한 가장 작은 아티팩트(artipact)다. 즉, 포드에 있는 모든 컨테이너가 동일한 머신에 있음을 뜻한다. Pod에 있는 각 컨테이너는 각자의 cgroup을 운영하지만 몇가지 Linux 네임스페이스는 공유한다. Pod의 각 컨테이너는 각자의 cgroup 을 운영하지만 몇가지 리눅스 네임스페이스를 공유하며, 서로 다른 파드는 각 애플리케이션이 격리되어 있고 각기 다른 IP주소와 호스트네임을 갖는다. 또한 System V IPC나 POSIX 메시지 큐(IPC 네임스페이스)를 통해 기본 프로세스 간 통신 채널을 사용해 서로 통신할 수 있다. 동일한 노드에서 동작하는 서로 다른 Pod의

Pod Readiness and Probes

Pord readiness is and additional indication of whether the pod is ready to serve traffic. Pod readiness determines whether the pod address shows up in the Endpoints object from an external source. Other Kubernetes resources that manage pods, like depolyments, take pod readiness into account for decision-making, such as advancing during a rolling update. During rolling deployment, a new pod becomes

Pod 생성과정

관리자가 애플리케이션을 배포하기 위해 ReplicaSet을 생성하면 다음과 같은 과정을 거쳐 Pod을 생성한다. 흐름을 보면 각 모듈은 서로 통신하지 않고 오직 API Server와만 통신하는 것을 알 수 있다. API Server를 통해 etcd에 저장된 상태를 체크하고 현재 상태와 원하는 상태가 다르면 필요한 작업을 수행한다. 각 모듈이 하는 일을 보면 다음과 같다. kubectl ReplicaSet 명세를 yml파일로 정의하고 kubectl 도구를 이용하여 API Server에 명령을 전달 API Server는 새로운 ReplicaSet Object를 etcd에 저장 Kube Controller Kube Controller에 포함된 ReplicaSet Controller가 Replica

Rolling Update는 k8s의 업데이트 방법 중 하나로, 새로운 버전의 애플리케이션을 배포하고 기존 버전을 점진적으로 대체하는 과정으로 진행된다. 새로운 버전의 Pod로 트래픽이 전달되기 전까지 기존 버전이 유지되므로 무중단으로 애플리케이션을 업데이트 가능한 장점이 있다. 그러나 새로운 버전의 Pod와 기존 Pod가 함께 유지되는 기간이 존재하기 때문에 업데이트 중에 리소스를 더 사용할 수 있다. 기본적으로 Rolling Update는 다음과 같은 단계로 이뤄진다. 새로운 버전의 애플리케이션을 배포한다. 이때 기존 버전은 유지된 상태로 새로운 버전의 Pod가 함께 생성된다. 새로운 버전의 Pod가 정상적으로 동작하고, 준비 상태가 되면, 이전 버전의 Pod을 하나씩 종료한다. 이때 제거되는 Pod

Service와 port

쿠버네티스 환경에서 Service는 Pod들을 통해 실행되고 있는 애플리케이션을 네트워크에 노출(expose)시키는 가상의 컴포넌트다. 쿠버네티스 내부의 다양한 객체들이 애플리케이션과, 그리고 애플리케이션이 다른 외부의 애플리케이션이나 사용자와 연결될 수 있도록 도와주는 역할을 한다. 쿠버네티스에 Service가 있는 이유는, Pod들이 반영속적인 특성을 가지고 있기 때문이다. 쿠버네티스에서의 Pod는 무언가가 구동 중인 상태를 유지하기 위해 동원되는 일회성 자원으로 언제든 다른 노드로 옮겨지거나 삭제될 수 있다. 또한 Pod는 생성될 때마다 새로운 내부 IP를 받게 되므로, 이것만으로 클러스터 내/외부와의 통신을 계속 유지하기 어렵다. 따라서 쿠버네티스는 Pod가 외부와 통신할 수 있도록 클러스터 내부에서

StatefulSets are a workload abstraction in Kubernetes to manage pods like you would a deployment. Unlike a deployment, StatefulSets add the following features for applications that require them: Stable, unique network identifiers Stable, persistent storage Ordered, graceful deployment and scaling Ordered, automated rolling updates The deployment resource is better suited for applications that d

인그레스(ingress)는 클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리한다. 인그레스는 부하 분산, SSL 종료, 명칭 기반의 가상 호스팅을 제공할 수 있다. 인그레스는 클러스터 외부에서 클러스터 내부 서비스로 HTTP와 HTTPS 경로를 노출한다. 트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다. 인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다. 인그레스 컨트롤러는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다. 인그레

가상 IP와 서비스 프록시

쿠버네티스 클러스터의 모든 노드는 kube-proxy를 실행한다. kube-proxy는 ExternalName 이외의 유형의 서비스에 대한 “가상 IP”의 역할을 한다. service를 조회했을때 나오는 cluster IP가 바로 k8s의 프록시로 만들어진 가상 IP이다. 이 IP는 k8s 내부에서만 접근할 수 있다. 쿠버네티스에서 가상 IP를 사용하는 이유 쿠버네티스가 프록시를 통해 가상 IP를 만드는 이유는, 실제 IP와 DNS를 사용하기 부적절하기 때문이다. k8s의 서비스 객체는 IP를 할당할 수 있는 기기가 아니고 잠시 생겼다가 사라질 수 있는 유한한 존재이다. 하지만 서비스를 식별하고 호출할 수 있는 무언가가 필요하기 때문에 그 방법으로서 프록시로 만든 가상 IP를 사용하는 것이다. ku

사이드카 패턴

사이드카 패턴이란 쿠버네티스와 같이 컨테이너 오케스트레이션 툴에서 구성할 수 있는 컨테이너 배치 패턴으로, 마치 오토바이 옆에 붙어 있는 사이드카와 비슷한 형태이다. 장점 1. 기존 로직의 변경 없이 기능 추가 사이드카 컨테이너를 통해 기존의 로직은 그대로 놔둔체 새로운 기능을 덧붙일 수 있다. 예를 들어 기존 http 프로토콜에 대해서만 서비스를 하는 웹서버에 tls layer를 추가하고 싶은 경우, 메인 컨테이너인 기존의 legacy 웹서버는 그대로 놔둔체 사이드카 컨테이너를 통해 https 서비스를 클라이언트에게 제공할 수 있다. 2. 컨테이너 재사용성 사이드카 컨테이너를 단일한 기능을 하게 모듈화하면 다른 곳에서 재사용하기 수월해진다. 대부분의 app에서는 로깅, 실행 프로세스 정보 확인 등의

10 most common mistakes using kubernetes

We had the chance to see quite a bit of clusters in our years of experience with Kubernetes (both managed and unmanaged on GCP, AWS and Azure), and we see some mistakes being repeated. No shame in that, we’ve done most of these too! Let’s try to show the ones we see very often and talk a bit about how to fix them. 1. resources requests and limits CPU request are usually either not set or sey ver

k8s에서 kubectl과 같은 커맨드를 사용해 API를 요청하는 과정은 크게 3가지로 구성되어 있다. ‘k8s 사용자가 맞느냐’를 판단하는 Authentication 두 번째는 ‘API를 호출할 수 있는 권한이 있느냐’를 판단하는 Authorization 마지막으로 그 요청이 적절한지를 판단하는 Admission Controller이다. Authorization와 Admission Controller는 k8s에 내장되어 있는 기능이기 때문에 사용 방법이 비교적 정해져 있는 반면, 첫 번째 단계인 Authentication은 이렇다 할 정답이 딱히 정해져 있지 않다. 물론 k8s의 자체 인증 기능인 ServiceAccount, 인증서 등을 사용할 수는 있지만, 사내에서 LADP, Google, Githu

OIDC Authentication with Dex

OIDC (Open ID Connect) 인증 방법은 OAuth2 위에서 동작하는 인증으로, Github이나 Google과 같이 서드 파티에서 부여받은 OAuth 권한을 통해 쿠버네티스의 인증을 수행한다. 기존에 사용하던 OAuth 인증 방법을 쿠버네티스에 그대로 가져온다고 생각하면 이해하기 쉽다. OIDC 인증 방법은 OAuth + JWT 토큰을 사용한다는 점에서 Webhook Token 인증 방법과 차이점을 갖는다. OAuth 토큰을 관리하기 위한 중간 서버를 구현한 Dex를 사용하여 OIDC 인증을 구현해보자. Dex Concept Dex는 서드 파티로부터 OAuth 인증 토큰을 가져와 관리하는 인증 도구이다. OAuth를 사용하기 위해 반드시 Dex를 써야 하는 것은 아니지만, Dex는 OAuth 서

Security Context for a Pod or Container

A security context defines privilege and access control settings for a Pod or Container. Security context settings include, but are not limited to: Descretionary Access Control: Permission to access an object, like a file, is based on user ID (UID) and group ID (GID). Security Enhanced Linux (SELinux): Objects are assigned security labels. Running as privileged or unprivileged. Linux Capabilities

Token Webhook with Guard

Webhook 서버에 인증 데이터를 전달한 뒤, 클라이언트가 유효한지 인증하여 Third party에 권한을 부여하는 Webhook Token 인증 방법에 대해 알아보자. 사용자는 미리 인증 데이터를 발급받아 놓고, 사용자가 인증 데이터를 Bearer 헤더에 담아서 REST API 요청을 보내면 API 서버는 클라이언트가 유효한지를 검증하기 위해 Webhook 서버에 인증 데이터를 전달한다. Webhook 서버는 해당 데이터를 검사한 뒤, 인증 여부를 API 서버에 반환하는 간단한 방식으로 되어 있다 Token Webhook, OIDC 중 어느 방법을 선택하든지에 상관 없이 클라이언트는 HTTP의 Bearer 헤더에 인증 데이터를 담아서 보내기만 하면 된다. 클라이언트는 인증 방법이 무엇인지 알 필요가

k8s 클러스터 root CA를 통한 사용자 인증

k8s는 기본적으로 root CA 인증서를 스스로 발급해 사용한다. 이 인증서를 이용하면 별도의 Third-party 연동 없이도 User와 Group을 사용할 수 있다. 단, 이 방법은 여러모로 한계점이 많기 때문에 가능하면 사용하지 않는 것이 좋다. 인증서가 유출되었을 때 revoke가 힘들기도 하고, 파일 단위로 인증 정보를 관리하는 것은 매우 비효율적이고 보안에 취약하기 때문이다. 따라서 k8s는 인증서 발급을 통한 사용자 인증은 극히 제한된 경우에만 사용하고 있다. 대표적으로는 관리자 권한을 가져야 하는 system:master 그룹의 인증 정보를 생성한다거나 (/etc/kubernetes/admin.conf), k8s의 핵심 컴포넌트에 인증서를 발급한다거나 할 때가 이에 해당한다. 우선, k8s는

kubernetes 에서 ingress 상에서 https를 서비스하는데 지원을 해주는 모듈이다. cert manager 설치 Terminal windowkubectl create namespace cert-managerkubectl apply --validate=false -f or kubectl apply --validate=false -f create namespace cert

Let’s set up role-based access control (RBAC) suitable for running the cluster in production. We will cover roles for using Calico. General RBAC for a production Kubernetes cluster is beyond the scope of this lab. Using calicoctl In order for the calicoctl tool to perform version mismatch verification (to make sure the versions for both the cluster and calicoctl are the same), whoever is using it

K8s를 위한 SpringBoot 개발

참고: Dockerize Spring Boot Application을 dockerize 하는 방법은 대표적으로 Jib, Buildpacks, Dockerfile 세가지가 있다. 이 중 Jib는 build time이 빠르고 (효율적인 layering), image 사이즈를 가장 작세 만들 수 있다는 장점을 가지고있다. Jib의 사용법은 간단하다. 아래와 같이 build.gradle에 jib gradle plugin을 추가하면 된다. plugins { id 'com.google.cloud.tools.jib' version '3.2.0'} 그리고 ./gradlew jib을 통해 im

NetworkPolicy Cilium example

Using the same KIND cluster from the Cilium install, let’s deploy the Postgres database(database.yaml) with the follwing YAML and kubectl Terminal window$ kubectl apply -f database.yamlservice/postgres createdconfigmap/postgres-config createdstatefulset.apps/postgres created Here we deploy our web server as a Kubernetes deployment(web.yaml) to our KIND cluster: Terminal window$ kubectl apply -f we

Pulling images from ECR on Kubernetes

If you are getting the HTTP 403 (Forbidden) error or the error message no basic auth credentials when trying to pull an image from ECR you are most likely doing so without logging into it first. This is going to happen if we are running a Kubernetes cluster on EC2 instances instead of using EKS. To be able to authenticate before pulling images on Kubernetes we need to use the imagePullSecrets attr

SpringBoot 서비스를 위한 Kubernetes 설정

출처: Deployment 아래는 deployment설정의 예시이다. apiVersion: apps/v1kind: Deploymentmetadata: name: main-server labels: app: main-serverspec: selector: matchLabels: app: main-server template: metadata: labels: app: main-server spec: affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDur

kubectl context

쿠버네티스 클러스터를 관리하는 cli 도구인 kubectl에는 환경을 바꿔가며 클러스터를 관리할 수 있도록 “context”라는 개념이 존재한다. context 는 kubectl 을 깔면 생성되는 파일인 ~/.kube/config 파일에서 설정할 수 있다. apiVersion: v1clusters:cluster: insecure-skip-tls-verify: true server: name: local-clustercluster: certificate-authority-data: ~~~~ server: name: gcp-cluster users:name: local-user user: blah

minukube 시작하기

1. kubectl을 설치한다. 버전은 1.22로 통일한다. linux 기준 명령어는 다음과 같다. Terminal windowcurl -o kubectl mac 기준 명령어는 다음과 같다. Terminal windowcurl -o kubectl window 기준 명령어는 다음과 같다. Terminal windowcurl -o kubectl.exe

환경변수 설정

포드의 구성 파일 안에서 정의한 환경 변수는 파드의 컨테이너를 위해 설정하는 커맨드와 인자들과 같이, 구성 파일 안의 다른 곳에서 사용할 수 있다. 아래의 구성 파일 예시에서, GREETING, HONORIFIC, 그리고 NAME 환경 변수들이 각각 Warm greetings to, The Most honorable, 그리고 Kubernetes로 설정되어 있다. 이 환경 변수들은 이후 env-print-demo 컨테이너에 전달되어 CLI 인자에서 사용된다. apiVersion: v1kind: Podmetadata: name: print-greetingspec: containers: name: env-print-demo image: bash env: name: GREETING v

Downtime 없는 Spot Instance 클러스터 구축 과정

Xquare 인프라 가용성 높은 spot instance 클러스터를 구축한 경험에 대해 이야기하기 전에 해당 인프라를 구축했던 Xquare 인프라 프로젝트에 대해 먼저 설명해보겠다. Xquare 인프라란 대덕소프트웨어마이스터고에 있는 여러 동아리의 프로젝트를 한 인프라에서 통합하여 관리하기 위한 프로젝트이다. PaaS 형태의 통합 인프라를 통해 학생들이 서버 성능이나 관리, 비용 부담 없이 프로젝트를 배포하고 사용할 수 있도록 하는 것이 목적이다. 각 동아리가 신청 폼으로 액세스 키를 발급받으면, 제공되는 배포 파이프라인을 통해 Xquare 인프라에 프로젝트를 마음껏 올릴 수 있다. 프로젝트 진행 시에 서버 관리나 비용에 대해 신경 쓸 필요 없이 빠르게 배포할 수 있게 된다. 현재 5개 동아리에서 개발하는