Why do need a Deploy Interface?
- Kubernetes is a very complex system.
- ex) pod, deployment, svc, secrets, configmap, daemonset, hpa ...
- Deployment points of interest are all different.
Deploy Manifest
- DockerFile build path
- list of configurations to use
- Deploying workloads (Deployment, ReplicaSet, StatefulSet, DaemonSet, CronJob ...)
- Workfload Resource Spec
- Serving ports
- Pod lifecycle, HealthCheck ...
- Ingress settings for traffic
Distinctive Points of the Deployment Manifest
- host mapping
- istio gateway - ingress, egress
- virtual service resource
example)
services:
app:
image: app
class: s1.xlarge
ports:
- name: http
port: 8080
- name: grpc
port: 8081
routes:
- name: "http"
protocol: http
host:
- scope: public
backend:
- service: app
port: http
- name: "grpc"
protocol: grpc
host:
- scope: internal
backend:
- service: app
port: grpc
-
For haproxy or nginx to run a separate process for grpc
-
class: s1.xlarge
: resources.limits.cpu: 4000m ….
→
export const instanceClassMap = new Map([
['s1.nano', {
limits: { cpu: '1000m', memory: '500Mi' },
requests: { cpu: '1000m', memory: '500Mi' }
}],
['s1.micro' ... ]
])
Developer creates a deployment manifest (deploy/values.yaml for each repo), goes through the template engine, and deployment system enters the kubernetes manifest to apply
- Template Engine
Helm Template
- cdk8s
- A development framework that allows you to create Kubernetes manifests in any programming language.
- java, typescript, javascript, golang, python …
- Portability to other programs is good.
- ex) Provided as an npm package
- Build structures around frequently changing values
- Region in which it is deployed
- Configuration in which it is deployed
- Built image tag
- Application config list ...
- Values that don't change often
- Components of the app
- Ports of the app
- Configure app's health check
- configure settings ...
kustomize
helmfile