kubernetes实践(四)组件创建及命令

By prince No comments

一.pods

1.Namespace

(1)创建命名空间

文件方式
kubectl create/apply -f myns-namespace.yaml

命令方式
kubectl create namespace myns

myns-namespace.yaml 文件

apiVersion: v1
kind: Namespace
metadata:
  name: myns

(2)查询命名空间

kubectl get namespaces/ns

(3)删除命名空间

文件方式
kubectl delete -f myns-namespace.yaml

命令方式
kubectl delete namespace myns

2.pod组件

(1)创建pod

a.创建nginx_pod.yaml文件

apiVersion: v1
kind: Pod
metadata:
   name: nginx-pod
labels:
   app: nginx
spec:
  containers:
   - name: nginx-container
     image: nginx
     ports:
     - containerPort: 80

b.根据该nginx_pod.yaml文件创建pod

kubectl apply -f nginx_pod.yaml

(2)查询所有资源

#查询所有命名空间所有类型资源
kubectl get all --all-namespaces -o wide

#查询默认命名空间所有类型资源
kubectl get all -o wide

#查询指定命名空间所有类型资源
kubectl get all -o wide -n namespace

(3)查询pod列表

#查询所有命名空间pod资源
kubectl get pods --all-namespaces -o wide

#查询默认命名空间pod资源
kubectl get pods -o wide

#查询指定命名空间pod资源
kubectl get pods -o wide -n namespace

(4)删除pod

kubectl delete -f pod_nginx.yaml

kubectl delete pod nginx

(5)查询pod详细信息

#查询默认命名空间pod详细信息
kubectl describe pod nginx

#查询指定命名空间pod详细信息
kubectl describe pod nginx -n namespace

(6)进入pod里的容器

kubectl exec -it nginx bash

kubectl exec -it nginx bash -n namespace

(7)查询pod日志

kubectl logs nginx

(8)端口转发

kubectl port-forward nginx 8888:80

3.Labels and Selectors

在前面的yaml文件中,看到很多label,顾名思义,就是给一些资源打上标签的

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx

表示名称为nginx-pod的pod,有一个label,key为app,value为nginx。

我们可以将具有同一个label的pod,交给selector管理

apiVersion: apps/v1
kind: Deployment
metadata: 
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:             # 匹配具有同一个label属性的pod标签
    matchLabels:
      app: nginx         
  template:             # 定义pod的模板
    metadata:
      labels:
        app: nginx      # 定义当前pod的label属性,app为key,value为nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

查看pod的label标签:

kubectl get pods --show-labels

二.Controllers

1.ReplicationController(RC)组件

ReplicationController定义了一个期望的场景,即声明某种Pod的副本数量在任意时刻都符合某个预期值,所以RC的定义包含以下几个部分:

  • Pod期待的副本数(replicas)

  • 用于筛选目标Pod的Label Selector

  • 当Pod的副本数量小于预期数量时,用于创建新Pod的Pod模板(template)

也就是说通过RC实现了集群中Pod的高可用,减少了传统IT环境中手工运维的工作。

(1)创建rc

a.创建nginx_replication.yaml文件

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

b.根据nginx_replication.yaml创建pod

kubectl apply -f nginx_replication.yaml

(2)查询rc列表

#查询所有命名空间rc资源
kubectl get rc --all-namespaces -o wide

#查询默认命名空间rc资源
kubectl get rc -o wide

#查询指定命名空间rc资源
kubectl get rc -o wide -n namespace

(3)查询rc详细信息

#查询默认命名空间rc详细信息
kubectl describe rc nginx

#查询指定命名空间rc详细信息
kubectl describe rc nginx -n namespace

(4)尝试删除一个pod

kubectl delete pod nginx-g26np
kubectl get pods

(5)扩容缩减pod副本集

#扩容
kubectl scale rc nginx --replicas=5

#缩减
kubectl scale rc nginx --replicas=2

(6)删除rc

kubectl delete -f nginx_replication.yaml

kubectl delete rc nginx

2.ReplicaSet(RS)组件

在Kubernetes v1.2时,RC就升级成了另外一个概念:Replica Set,官方解释为“下一代RC”

ReplicaSet和RC没有本质的区别,kubectl中绝大部分作用于RC的命令同样适用于RS

RS与RC唯一的区别是:RS支持基于集合的Label Selector(Set-based selector),而RC只支持基于等式的Label Selector(equality-based selector),这使得Replica Set的功能更强

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: frontend
spec:
  matchLabels: 
    tier: frontend
  matchExpressions: 
    - {key:tier,operator: In,values: [frontend]}
  template:
  ...

注意:一般情况下,我们很少单独使用Replica Set,它主要是被Deployment这个更高的资源对象所使用,从而形成一整套Pod创建、删除、更新的编排机制。当我们使用Deployment时,无须关心它是如何创建和维护Replica Set的,这一切都是自动发生的。同时,无需担心跟其他机制的不兼容问题(比如ReplicaSet不支持rolling-update但Deployment支持)。

3.Deployment组件

(1)创建deployment

a.创建nginx_deployment.yaml文件

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

b.根据nginx_deployment.yaml文件创建pod

kubectl apply -f nginx_deployment.yaml

(2)查询deployment列表

#查询所有命名空间deployment资源
kubectl get deployment --all-namespaces -o wide

#查询默认命名空间deployment资源
kubectl get deployment -o wide

#查询指定命名空间deployment资源
kubectl get deployment -o wide -n namespace

(3)查询deployment详细信息

#查询默认命名空间deployment详细信息
kubectl describe deployment nginx-deployment

#查询指定命名空间deployment详细信息
kubectl describe deployment nginx-deployment -n namespace

(4)删除deployment

kubectl delete -f nginx_deployment.yaml

kubectl delete deployment nginx-deployment

(5)修改deployment配置(即时生效)

kubectl edit deployment nginx-deployment

(6)更新nginx的image版本(滚动更新)

kubectl set image deployment nginx-deployment nginx=nginx:1.9.1

(7)查询deployment历史记录

kubectl rollout history deployment nginx-deployment

(8)回滚deployment

kubectl rollout undo deployment nginx-deployment

4. StatefulSets组件

之前接触的Pod的管理对象比如RC、Deployment、DaemonSet和Job都是面向无状态的服务,但是现实中有很多服务是有状态的,比如MySQL集群、MongoDB集群、ZK集群等,它们都有以下共同的特点:

  • 每个节点都有固定的ID,通过该ID,集群中的成员可以互相发现并且通信
  • 集群的规模是比较固定的,集群规模不能随意变动
  • 集群里的每个节点都是有状态的,通常会持久化数据到永久存储中
  • 如果磁盘损坏,则集群里的某个节点无法正常运行,集群功能受损

而之前的RC/Deployment没办法满足要求,所以从Kubernetes v1.4版本就引入了PetSet资源对象,在v1.5版本时更名为StatefulSet。从本质上说,StatefulSet可以看作是Deployment/RC对象的特殊变种

  • StatefulSet里的每个Pod都有稳定、唯一的网络标识,可以用来发现集群内其他的成员
  • Pod的启动顺序是受控的,操作第n个Pod时,前n-1个Pod已经是运行且准备好的状态
  • StatefulSet里的Pod采用稳定的持久化存储卷,通过PV/PVC来实现,删除Pod时默认不会删除与StatefulSet相关的存储卷
  • StatefulSet需要与Headless Service配合使用

(1)创建StatefulSet

a.创建nginx-st.yaml文件

# 定义Service
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
# 定义StatefulSet
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx 
  serviceName: "nginx"  
  replicas: 3 
  template:
    metadata:
      labels:
        app: nginx 
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
          name: web

b.根据nginx-st.yaml文件创建StatefulSet

kubectl apply -f nginx-st.yaml

5.DaemonSet组件

DaemonSet应用场景

  • 运行集群存储 daemon,例如在每个节点上运行 glusterdceph
  • 在每个节点上运行日志收集 daemon,例如fluentdlogstash
  • 在每个节点上运行监控 daemon,例如 Prometheus Node Exportercollectd、Datadog 代理、New Relic 代理,或 Ganglia gmond

6.Jobs组件

对于RS,RC之类的控制器,能够保持Pod按照预期数目持久地运行下去,它们针对的是持久性的任务,比如web服务。

而有些操作其实不需要持久,比如压缩文件,我们希望任务完成之后,Pod就结束运行,不需要保持在系统中,此时就需要用到Job。

所以可以这样理解,Job是对RS、RC等持久性控制器的补充。

负责批量处理短暂的一次性任务,仅执行一次,并保证处理的一个或者多个Pod成功结束。

  • 非并行Job:
    • 通常只运行一个Pod,Pod成功结束Job就退出。
  • 固定完成次数的并行Job:
    • 并发运行指定数量的Pod,直到指定数量的Pod成功,Job结束。
  • 带有工作队列的并行Job:
    • 用户可以指定并行的Pod数量,当任何Pod成功结束后,不会再创建新的Pod
    • 一旦有一个Pod成功结束,并且所有的Pods都结束了,该Job就成功结束。
    • 一旦有一个Pod成功结束,其他Pods都会准备退出。

(1)创建job

a.创建job.yaml文件

apiVersion: batch/v1
kind: Job
metadata:
  name: job-demo
spec:
  template:
    metadata:
      name: job-demo
    spec:
      restartPolicy: Never
      containers:
      - name: counter
        image: busybox
        command:
        - "bin/sh"
        - "-c"
        - "for i in 9 8 7 6 5 4 3 2 1; do echo $i; done"

b.根据job.yaml文件创建job

kubectl apply -f job.yaml

(2)查询job列表

#查询所有命名空间job资源
kubectl get job --all-namespaces -o wide

#查询默认命名空间job资源
kubectl get job -o wide

#查询指定命名空间job资源
kubectl get job -o wide -n namespace

(3)查询job详细信息

#查询默认命名空间job详细信息
kubectl describe job job-demo

#查询指定命名空间job详细信息
kubectl describe job job-demo -n namespace

(4)删除job

kubectl delete -f job.yaml

kubectl delete deployment job-demo

7.CronJob组件

cronJob是基于时间进行任务的定时管理。

  • 在特定的时间点运行任务
  • 反复在指定的时间点运行任务:比如定时进行数据库备份,定时发送电子邮件等等。

 

 

发表评论

 

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据