docker build -t dvm.adsplatformproxy:v1.0.0 . #build images docker run -e WWNamespace=dev -e ZKServerAddress=****** -p 6000:80 6cb913a34ae3 #run container,本地起进程 docker run -ti 6cb913a34ae3 /bin/bash #远程进入image文件;exit退出 docker rmi -f b54d6e186ef4 #远程删除image docker rmi -rf b54d6e186ef4 docker build -t dvm.adsplatformproxy:v1.0.0 . #build images docker run -e WWNamespace=dev -e ZKServerAddress=****** -p 6000:80 6cb913a34ae3 #run container,本地起进程 docker run -ti 6cb913a34ae3 /bin/bash #远程进入image文件;exit退出 docker rmi -f b54d6e186ef4 #远程删除image docker rmi -rf b54d6e186ef4
查看docker仓库的tag信息
For the latest (as of 2015-07-31) version of Registry V2, you can get this image from DockerHub:
docker pull distribution/registry:master
List all repositories (effectively images):
curl -X GET https://myregistry:5000/v2/_catalog
> {"repositories":["redis","ubuntu"]}
List all tags for a repository:
curl -X GET https://myregistry:5000/v2/ubuntu/tags/list
> {"name":"ubuntu","tags":["v14.04"]}
Docker pull:
docker pull https://myregistry:5000
/ubuntu
:v14.04
kubectl get deployment #获取发布 kubectl delete deployment **** #删除发布,自动删除service、pods
kubectl create ******.yaml #创建yaml,包含config、ingress配置 kubectl get ingress #获取ingress配置 kubectl get configmap #获取config配置
kubectl edit configmaps *****-config -n *namespace*
kubectl get configmap #1.获取配置文件 kubectl edit configmap ****** #2.修改配置文件
..\refreshconfig.ps1 -ConfigMapName dvm-website-config #3.psl更新配置 或者删除已有的pod,会自动创建pod并使用新的configmap
kubectl create -f rc-nginx.yaml kubectl replace -f rc-nginx.yaml kubectl edit po rc-nginx-btv4j kubectl delete -f rc-nginx.yaml kubectl delete po rc-nginx-btv4j kubectl delete po -lapp=nginx-2 kubectl describe po rc-nginx-2-btv4j # kubectl get namespace
kubectl get po <podname> -o #yaml 以yawl格式输出pod的详细信息。 kubectl get po <podname> -o json # 以json格式输出pod的详细信息。 kubectl get po rc-nginx-2-btv4j -o=custom-columns=LABELS:.metadata.labels.app #使用”-o=custom-columns=“定义直接获取指定内容的值
configmap 的更新
A new command, kubectl rolling-restart
that takes an RC name and incrementally deletes all the pods controlled by the RC and allows the RC to recreate them.
Small work around (I use deployments and I want to change configs without having real changes in image/pod):
- create configMap
- create deployment with ENV variable (you will use it as indicator for your deployment) in any container
- update configMap
- update deployment (change this ENV variable)
k8s will see that definition of the deployment has been changed and will start process of replacing pods
PS:
if someone has better solution, please share
It feels like the right solution here would enable you to restart a deployment, and reuse most of the deployment parameters for rollouts like MinReadyCount, while allowing for command-line overrides like increasing the parallelism for emergency situations where you need everything to bounce immediately.
We would also like to see this for deployments maybe like kubectl restart deployment some-api
Kubernetes is allowed to restart Pods for all sorts of reasons, but the cluster admin isn't allowed to.
I understand the moral stand that 'turn it off and on again' may not be a desired way to operate... but I also think it should be ok to let those people who wish to, to restart a Deployment without resorting to the range of less appetizing tricks like:
- deleting pods
- dummy labels
- dummy environment variables
- dummy config maps mapped to environment variable
- rebooting the worker nodes
- cutting the power to the data centre