docker 命令2

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":["14.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