Literal configuration of multiple objects (was Service up/down scripts) about kubernetes

[brendandburns]

Just don't call it config... ;)

[bgrant0607]

For now, we should ensure that it's straightforward to write robust, idempotent "up" and "down" scripts with our tools and APIs. I'd lump a more general declarative approach with update support.

[bgrant0607]

I filed another issue for idempotent creation (#148). We can use this issue for multi-resource declarative configuration, starting with up/down.

[bgrant0607]

@smarterclayton @brendandburns I suggest we use this issue to discuss literal (i.e., without parameterization and inheritance) instantiation of multiple objects.

[smarterclayton]

Namespace is inferred on creation - should it also be inferred on deletion? We don't have auto-naming yet, so we don't have unnamed resources.

[bgrant0607]

Closing in favor of #1905, which has more detail.

[maicohjf]

People are going to want to write scripts to bring an entire service up/down. We should provide a standard way of doing so now, or everyone is going to roll their own. This could mean python api bindings and a template or something else (a better go client library?).

Create a deployment spec file that will:
 Launch 7 replicas of the redis image with the label: app_env_stage=dev
 Deployment name: kual00201
Save a copy of this spec file to /opt/KUAL00201/deploy_spec.yaml (or .json)
When you are done, clean up (delete) any new k8s API objects that you produced during this task

apiVersion: apps/v1
kind: Deployment
metadata:
name: kual00201
spec:
replicas: 7
selector:
matchLabels:
app_env_stage: dev
template:
metadata:
labels:
app_env_stage: dev
spec:
containers:
- name: redis
image: redis
kubectl create -f kual00201.yaml
cp kual00201.yaml /opt/KUAL00201/deploy_spec.yaml
可以输出
kubectl delete deploy kual00201