kubernetes资源 极速快三网站出租组织、管理介绍

  • 时间:
  • 浏览:4
  • 来源:uu快3倍率_uu快3网游_单双计划

$ vi /tmp/nginx.yaml

$ kubectl run my-nginx --image=nginx:1.7.9 --replicas=3

$ kubectl label pods -l app=nginx tier=fe

...

pod "my-nginx-2035384211-u3t6x" labeled

$ kubectl delete deployment,services -l app=nginx

$ kubectl get pods -Lapp -Ltier -Lrole

│ └── my-deployment.yaml

# do some edit, and then save the file

replicas: 3

my-nginx-2035384211-j5fhi 1/1 Running 0 150m

指定--recursive 可能性 -R,则会遍历目录及其下的所有子目录:

my-nginx-2035384211-j5fhi 1/1 Running 0 23m fe

deployment "my-nginx" replaced

├── configmap

kubectl create命令支持多个-f选项,如:

track: canary

guestbook-fe-ght6d 1/1 Running 0 1m guestbook frontend <none>

# https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/cluster-administration/nginx-app.yaml

deployment "my-nginx" deleted

apiVersion: apps/v1

track: stable

$ kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx'

deployment "my-nginx" autoscaled

guestbook-redis-master-5pg3b 1/1 Running 0 1m guestbook backend master

app: nginx

containers:

spec:

kubectl run命令属于kubectl管理对象有三种最好的措施中的“祈使命令”最好的措施。以上命令会创建有另另另另五个 deploment类型的Pod,副本数据为3,实例镜像为nginx:1.7.9。可能性打算将nginx版本从1.7.9升级到1.9.1,执行如下命令:

pod "my-nginx-2035384211-j5fhi" labeled

image: nginx:1.7.9

replicas: 1

kubectl命令会读取目录下所有后缀为.yaml, .yml, or .json的文件。

...

my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe

ports:

tier: frontend

对于更大的资源数量,都助于 很容易的通过为命令行指定标签查询选择器过虑出助于 操作的资源,如使用-l --selector等选项:

创建最好的措施与单个资源相同,只需运行一次创建命令即可:

app: guestbook

selector:

本文转自开源中国-kubernetes资源 暗影快三网站出租组织、管理介绍

可能性可能性 暗影快三网站出租haozbbs.com Q14465915067在kubenetes中部署了应用,并通过service的形式将它 暴露出去。接下来呢?kubenetes提供了大量工具帮助用户管理应用的部署、弹性伸缩、升级等。

image: gb-frontend:v3

selector:

$ kubectl create -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml

资源会依在配置文件中跳出的顺序依次创建,否则 ,最好首先指定助于 创建的service,可能性这将确保调度应用程序助于将与服务相关联的pod展开,可能性它们是由控制器创建的,比如deployment。

注意,kubectl apply管理资源的最好的措施称为“声明对象配置”,其在系统中的实时对象,在其注解中会保存一份历史配置。当对你你这种对象更新时,系统参考配置文件、实时对象注解、实时对象在系统中的实际配置有另另另另五个 方面的计算,最后决定咋样更新对象。

my-nginx-svc 10.0.0.208 <pending> 150/TCP 0s

可能性你你这种最好的措施是通过标签选择器过虑出符合条件的资源,不多要求严格规范标签的使用,否则 容易处在误操作。

labels:

deployment "my-nginx" scaled

$ rm /tmp/nginx.yaml

└── pvc

guestbook-redis-slave-2q2yf 1/1 Running 0 1m guestbook backend slave

│ └── my-configmap.yaml

description: my frontend running nginx

在现实的使用场景中,有另另另另五个 资源往往助于 加入多个标签,以便不多同的维度上将资源划归到不同的集合中。这种gustbook中前端:

tier: frontend

当执行如一命令助于 报错,导致 分析是默认情况汇报下只防止目录的第一次,不多深入防止目录下的子目录:

- name: nginx

labels:

NAME READY STATUS RESTARTS AGE

目前助于另另另另五个 多nginx的Pod实例:

labels:

deployment "my-nginx" deleted

以上命令输出所有符合“app=nginx”条件的Pod,-L tier指示在输出结果中加进额外的列显示tier标签内容。

$ kubectl apply -f docs/concepts/cluster-administration/nginx/nginx-deployment.yaml

*** 还是应该将资源的定义分隔成单独的文件,否则 再将相关的文件通过目录的形式组织在一块儿,防止单个文件内容过大过于简化。

$ kubectl get pods -l app=nginx

资源创建不多kubectl命令能实现的唯一批量操作。它也都助于 从资源配置文件中提取出资源名称实现其它操作,一阵一阵是删除指创建的资源:

guestbook-redis-slave-qgazl 1/1 Running 0 3m

app: guestbook

也可指定目录:

用“role”标签区分master与slave角色。

deployment "my-nginx" created

role: slave

也都助于 通不多层目录组织资源,运行命令时指定--recursive、-R与--filename、-f选项,则命令遍历整个目录,实现对所有资源的批防止。假设处在着如下目录:

template:

service "my-nginx-svc" deleted

metadata:

...

labels:

app: guestbook

name: frontend

spec:

guestbook-redis-slave-2q2yf 1/1 Running 0 3m

deployment "my-nginx" configured

有另另另另五个 标签分别标识资源的app各类与所属的层级。

labels:

project/k8s/development

persistentvolumeclaim "my-pvc" created

my-nginx-o0ef1 1/1 Running 0 29m nginx <none> <none>

app: nginx

spec:

apiversion: v1

annotations:

kind: pod

deployment "my-nginx" configured

NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE

deployment "my-nginx" created

app: nginx

可能性:

guestbook-fe-4nlpb 1/1 Running 0 1m guestbook frontend <none>

tier: backend

系统中实时对象的或多或少属性独立于配置文件变化,破坏性更新的本质是忽略掉哪几个属性的变更,首先将实时对象的配置从系统中删否则 再将新的配置文件应用到系统中,如下:

name: my-nginx

name: my-nginx-svc

deployment "my-nginx" deleted

metadata:

service "my-nginx-svc" deleted

$ kubectl get pods -l app=nginx -L tier

NAME READY STATUS RESTARTS AGE TIER

replicas: 3

image: gb-frontend:v4

kubectl命令执行时助于 资源名称,与命令执行后输出的资源名称语法相同,否则 很容易利用管道、$()、xargs等技术将之个命令组合在一块儿,这种:

推荐的管理配置文件的最好的措施是与版本控制系统集成,与GIT,否则 通过kubectl apply将GIT中的配置文件应用到集群中,从而实现配置文件与集群中实时配置的版本控制。kubectl apply命令本质上是计算配置文件与系统中实时对象配置的差值,再通过补丁的形式将你你这种差值应用到系统中,而助于 从整体上替换掉系统中的配置,这样 不多丢失这样 独立于配置的属性从而防止破坏性更新。

$ kubectl create -f project/k8s/development --recursive

通过kubectl scale调整实例个数,将nginx实例的副本数据从3减少到1:

type: LoadBalancer

- containerPort: 150

app: guestbook

上述命令,首先执行kubectl create创建docs/concepts/cluster-administration/nginx/目录下指定的资源,可能性指定了-o name选项,输出结果的格式被设定为“resource/name”格式,再通过管理将输出传递给grep命令,将其中的service资源检出,结果作为kubectl get的参数。

role: master

---

可能性助于有另另另另五个 资源,不多直接使用命令行,通过resource/name也很容易实现:

pod "my-nginx-2035384211-u2c7e" labeled

$ kubectl create -f project/k8s/development

labels:

app: nginx

...

不多应用要求一块儿创建多个资源,比如deployment与service等。管理多个相关资源的有三种简单的最好的措施是将它们简单的组织在有另另另另五个 文件中(在YAML格式的文件中通过 --- 分隔),如下例:

注解属于注释性、非标识性的元数据,对已处在的资源追加注解的最好的措施如下:

$ kubectl get deployment my-nginx -o yaml > /tmp/nginx.yaml

用kubectl label命令对可能性处在的Pod可能性其它资源重新打标签,如下:

guestbook-redis-slave-qgazl 1/1 Running 0 1m guestbook backend slave

- port: 150

kind: Deployment

app: guestbook

对于新发布版本,“track”标签的值为“canary”。

configmap "my-config" created

├── deployment

$ kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service)

apiVersion: v1

通过指定标签不多同的维度组织资源:

$ kubectl replace -f docs/concepts/cluster-administration/nginx/nginx-deployment.yaml --force

都助于 调整稳定版与测试版副本的数据,从而决定两者处在理的流量比例。经过一定时间的测试后,可能性这样 问題图片。则都助于 将所有“track”为“stable”的实例升级成最新版本,并将“track”为“canary”的实例删除,从而完成版本升级。可能性跳出问題图片,只需将“canary”版本的实例删除即可。

ports:

$ kubectl delete -f https://k8s.io/docs/concepts/cluster-administration/nginx-app.yaml

有以后,对于可能性创建的资源,助于 进行精确的、无破坏性的更新。解释:前文中所涉及的更新最好的措施,属于kubectl管理对象有三种最好的措施中的“祈使对象配置”,在或多或少情况汇报下,你你这种更新最好的措施会产生破坏性。

...

在编辑器中将.spec.template.spec.containers[0].image的值由nginx:1.7.9改成nginx:1.1.1即可。kubenetes系统检测到配置变化助于 逐升级副本,始终有可用的实例从而保证服务不中断。

鼓励实践将相同微服务可能性是同层应用的所有配置文件集放满置在有另另另另五个 文件中,可能性是将紧密相关的文件放满到同有另另另另五个 目录之下。可能性同层应用是通过DNS彼此绑定,这样 就都助于 简单将堆栈中的不多组件一块儿部署。

$ kubectl autoscale deployment/my-nginx --min=1 --max=3

kind: Service

前文涉及到的资源通过kubectl create -f形式创建,你你这种最好的措施称为“祈使对象配置”,系统中的实时对象这样 含高历史配置的注解,助于 通过一定的最好的措施将资源的管理从“祈使对象配置”迁移到“声明对象配置”,推荐最好的措施:

└── my-pvc.yaml

app: guestbook

NAME READY STATUS RESTARTS AGE

metadata:

my-nginx-2035384211-u2c7e 1/1 Running 0 23m fe

标签的有另另另另五个 使用场景是区分同有另另另另五个 组件的不同发布版本可能性配置版本,常见的实践是用标签实现金丝雀部署。这种,使用“track”标签标识同一组件的不同版本。对于主力、稳定版本,“track”标签的值为“stable”。

$ kubectl apply -f /tmp/nginx.yaml

Redis中的master:

app: nginx

$ kubectl get pods -lapp=guestbook,role=slave

selector:

$ kubectl create -f https://k8s.io/docs/concepts/cluster-administration/nginx-app.yaml

guestbook-fe-jpy62 1/1 Running 0 1m guestbook frontend <none>

matchLabels:

deployment "my-deployment" created

Redis中的slave:

以上命令中-l app=nginx表示过滤条件,检出系统中所有app为nginx的组件,上方的tier=fe表示对检出的资源重新打上标签。确认结果:

$ kubectl get pods my-nginx-v4-9gw19 -o yaml

metadata:

error: you must provide one or more resources by argument or filename (.json|.yaml|.yml|stdin)

service "my-nginx-svc" created

这种首先执行如下命令:

tier: frontend

这样 ,同有另另另另五个 组件的有三种版本一块儿处在,使用的image不同,不同版本的实例通过“track”标签的值加以区分。前端服务的选择器通过指定有三种版本的共有标签从面含高组件的不同版本,如下:

$ kubectl scale deployment/my-nginx --replicas=1

labels:

my-nginx-divi2 1/1 Running 0 29m nginx <none> <none>

tier: frontend

name: frontend-canary

NAME READY STATUS RESTARTS AGE APP TIER ROLE

kubenetes支持设置副本数量的最小值与最大值,系统根据实例的负载情况汇报,在最大值与最小值之间动态动态调整副本数量实现自动伸缩。

tier: backend

labels: