作者:李萧明

一看必会系列:k8s 练习6 利用阿里云下载google k8s镜像

No Comments Kubernetes

 

 

 

链接: https://pan.baidu.com/s/1oZo2BF2AhNnR9ovGCRSPTw 提取码: 7u4t 复制这段内容后打开百度网盘手机App,操作更方便哦

一看必会系列:k8s 练习5 k8s调度给指定node

No Comments Kubernetes

 

查看当前node2信息
[root@k8s-master elk]#  kubectl describe node k8s-node2 |grep -C 5 Lab
Name:               k8s-node2
Roles:              <none>
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/hostname=k8s-node2
Annotations:        flannel.alpha.coreos.com/backend-data: {"VtepMAC":"3e:27:fd:0f:47:76"}
                    flannel.alpha.coreos.com/backend-type: vxlan
                    flannel.alpha.coreos.com/kube-subnet-manager: true
[root@k8s-master elk]#

1.来打个标 

命令如下 kubectl label nodes node名 随便写=随便写1

[root@k8s-master elk]# kubectl label nodes k8s-node2 mylabel=100
node/k8s-node2 labeled
[root@k8s-master elk]#  kubectl describe node k8s-node2 |grep -C 10 Lab
Name:               k8s-node2
Roles:              <none>
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/hostname=k8s-node2
                    mylabel=100    #〈--就是这个东西
Annotations:        flannel.alpha.coreos.com/backend-data: {"VtepMAC":"3e:27:fd:0f:47:76"}
                    flannel.alpha.coreos.com/backend-type: vxlan
                    flannel.alpha.coreos.com/kube-subnet-manager: true
                    flannel.alpha.coreos.com/public-ip: 192.168.10.71
                    kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
                    node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
[root@k8s-master elk]#

2.难后搞个容器试试
vim busybox-pod5.yaml
apiVersion: v1
kind: Pod
metadata:
  name: busybox-testxx4
  labels:
    name: busybox-pod-lb
spec:
  containers:
  – name: busybox-xxx4
    image: reg.ccie.wang/library/busybox:1.30.1
    command:
    – sleep
    – "3600"
  #使用下面命令进行node选择
  nodeSelector:
    mylabel: "100"

创建
kubectl apply -f busybox-pod5.yaml

验证

[root@k8s-master busybox]# kubectl get pod -o wide
NAME                       READY   STATUS    RESTARTS   AGE    IP             NODE        NOMINATED NODE   READINESS GATES
busybox-testxx4            1/1     Running   0          54s    10.244.2.88   k8s-node2   <none>           <none>
可以看到node2 上面去了

------中间广告---------

查看pod信息
[root@k8s-master busybox]# kubectl describe pod busybox-testxx4
Name:               busybox-testxx4
Labels:             name=busybox-pod-lb
IP:                 10.244.2.88
Containers:
  busybox-xxx4:
    Image:         reg.ccie.wang/library/busybox:1.30.1
    Command:
      sleep
      3600
      #新标标
Node-Selectors:  mylabel=100

Events:
  Type    Reason     Age    From                Message
  —-    ——     —-   —-                ——-
  Normal  Scheduled  4m17s  default-scheduler   Successfully assigned default/busybox-testxx4 to k8s-node2
  Normal  Pulled     4m16s  kubelet, k8s-node2  Container image "reg.ccie.wang/library/busybox:1.30.1" already present on machine
  Normal  Created    4m16s  kubelet, k8s-node2  Created container
  Normal  Started    4m16s  kubelet, k8s-node2  Started container
[root@k8s-master busybox]#

 

 

 

————报错  没起来
[root@k8s-master busybox]# kubectl get pod -o wide
NAME                       READY   STATUS        RESTARTS   AGE    IP             NODE        NOMINATED NODE   READINESS GATES
busybox-testxx1            0/1     Pending       0          38m    <none>         k8s-node2   <none>           <none>

[root@k8s-master busybox]# kubectl describe pod busybox-testxx1
Name:               busybox-testxx1
Namespace:          default
Priority:           0
PriorityClassName:  <none>
Node:               k8s-node2/
Labels:             name=busybox-pod-lb
Annotations:        <none>
Status:             Pending
IP:                
Containers:
  busybox-xxx1:
    Image:        busybox
Node-Selectors:  mylabel=100

Events:
  Type     Reason     Age                   From                Message
  —-     ——     —-                  —-                ——-
  Normal   Scheduled  3m32s                 default-scheduler   Successfully assigned default/busybox-testxx5 to k8s-node2
  Normal   Pulled     113s (x5 over 3m31s)  kubelet, k8s-node2  Container image "reg.ccie.wang/library/busybox:1.30.1" already present on machine
  Normal   Created    113s (x5 over 3m30s)  kubelet, k8s-node2  Created container
  Normal   Started    113s (x5 over 3m30s)  kubelet, k8s-node2  Started container
  Warning  BackOff    99s (x10 over 3m28s)  kubelet, k8s-node2  Back-off restarting failed container

对于像ubuntu这样的系统级docker ,用k8s集群启动管理后,会自动关闭,
解决方法就是 让其一直在运行,所以在yaml文件中增加command命令即可

原因是这里配错了
apiVersion: v1
kind: Pod
metadata:
  name: busybox-testxx1
  labels:
    name: busybox-pod-lb
spec:
  containers:
  – name: busybox-xxx1
    image: busybox
#需要增加命令3条
    command:
    – sleep
    – "3600"

  nodeSelector:
    mylabel: "100"
   
   
或者只要有进程运行就行。
     command: [ "/bin/bash", "-c", "–" ]
     args: [ "while true; do sleep 30; done;" ]

一看必会系列:k8s 练习4 pod滚动升级

No Comments Kubernetes

Pod滚动升级

rolling-update 可用在 滚动升级,回滚,POD重启等操作

正式配置文件在最下面

[root@k8s-master redis_rolling]#  kubectl rolling-update redis-master-rc-v2 -f redis-master-rc-v4.yaml
Command "rolling-update" is deprecated, use "rollout" instead

第一阶段
Created redis-master-rc-v4  #开始创建 redis-master-rc-v4
第二阶段
Scaling up redis-master-rc-v4 from 0 to 4,  #将 redis-master-rc-v4 加到4个副本
scaling down redis-master-rc-v2 from 2 to 0  #将 redis-master-rc-v2 从2减到0
(keep 4 pods available, don’t exceed 5 pods)
第三阶段
Scaling redis-master-rc-v4 up to 3  # redis-master-rc-v4 加到3
Scaling redis-master-rc-v2 down to 1 #V2 减到1
Scaling redis-master-rc-v4 up to 4  #V4 加到4
Scaling redis-master-rc-v2 down to 0 #V2 减到0
第4阶段
Update succeeded.
Deleting old controller: redis-master-rc-v2 #更新成功删除掉的rc-v2
Renaming redis-master-rc-v4 to redis-master-rc-v2  #将V4改名为V2
replicationcontroller/redis-master-rc-v2 rolling updated #升级完成
完成

验证
[root@k8s-master ~]# kubectl get rc,pod
NAME                                       DESIRED   CURRENT   READY   AGE
replicationcontroller/redis-master-rc-v2   2         2         2       11m
#刚执行,第1-2阶段,两个RC同时存在
replicationcontroller/redis-master-rc-v4   3         3         3       50s

NAME                           READY   STATUS    RESTARTS   AGE
#刚执行,第1-2阶段,两个RC同时存在
pod/redis-master-rc-v3-69rjr   1/1     Running   0          12m
pod/redis-master-rc-v3-vhnbs   1/1     Running   0          12m
pod/redis-master-rc-v4-cp9h8   1/1     Running   0          50s
pod/redis-master-rc-v4-jfhcx   1/1     Running   0          50s
pod/redis-master-rc-v4-nqqkp   1/1     Running   0          50s

过段时间之后 #第3-4阶段
[root@k8s-master ~]# kubectl get rc,pod
NAME                                       DESIRED   CURRENT   READY   AGE
#只剩一个了
replicationcontroller/redis-master-rc-v2   4         4         4       11m

NAME                           READY   STATUS      RESTARTS   AGE
只剩一个了
pod/redis-master-rc-v4-cp9h8   1/1     Running     0          14m
pod/redis-master-rc-v4-h5f6r   1/1     Running     0          13m
pod/redis-master-rc-v4-jfhcx   1/1     Running     0          14m
pod/redis-master-rc-v4-nqqkp   1/1     Running     0          14m
[root@k8s-master ~]# kubectl get rc,pod

使用命令进行 rolling-update 正常升级的结果是 原来的pod和rc会被替换掉,
新rc-v4会重命名为原来的rc-v2,保持服务正常

 

下面是直接用命令升级 kubectl rolling-update  现在的RC –image=要升级的镜像
[root@k8s-master ~]# kubectl rolling-update redis-master-rc  –image=kubeguide/redis-master:1.0
Command "rolling-update" is deprecated, use "rollout" instead
Found existing update in progress (redis-master-rc-v2), resuming.
Continuing update with existing controller redis-master-rc-v2.
Scaling up redis-master-rc-v2 from 1 to 1, scaling down redis-master-rc from 1 to 0 (keep 1 pods available, don’t exceed 2 pods)
Scaling redis-master-rc down to 0
Update succeeded. Deleting redis-master-rc
replicationcontroller/redis-master-rc-v2 rolling updated to "redis-master-rc-v2"

验证
[root@k8s-master yaml]# kubectl get rc,pod
NAME                                       DESIRED   CURRENT   READY   AGE

replicationcontroller/redis-master-rc-v2   1         1         1       19m 

NAME                           READY   STATUS    RESTARTS   AGE
pod/redis-master-rc-v2-2rc4x   1/1     Running   0          19m  #

[root@k8s-master yaml]# kubectl describe pod/redis-master-rc-v2-2rc4x
Name:               redis-master-rc-v2-2rc4x
Namespace:          default
Node:               k8s-node1/192.168.10.69
Labels:             deployment=4e423afb21f081b285503ab911a2c748
                    name=redis-master-lb
Containers:
  master:
    Image:          kubeguide/redis-master:1.0

Events:
  Type    Reason     Age   From                Message
  —-    ——     —-  —-                ——-
  Normal  Scheduled  28m   default-scheduler   Successfully assigned default/redis-master-rc-v2-2rc4x to k8s-node1
  Normal  Pulling    28m   kubelet, k8s-node1  pulling image "kubeguide/redis-master:1.0"
  Normal  Pulled     28m   kubelet, k8s-node1  Successfully pulled image "kubeguide/redis-master:1.0"
  Normal  Created    28m   kubelet, k8s-node1  Created container
  Normal  Started    28m   kubelet, k8s-node1  Started container
[root@k8s-master yaml]#

———–配置方式1------------
配置文件v2
redis-master-rc-v2.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: redis-master-rc-v2  #升级的不能一样
  labels:
    names: redis-master-lb-2   #升级的不能一样
spec:
  replicas: 2
  selector:
    name: redis-master-lb-2 #升级的不能一样
  template:
    metadata:
      labels:
        name: redis-master-lb-2  #升级的不能一样
    spec:
     containers:
     – name: master
       image: kubeguide/redis-master:1.0  #升级的不能一样
       ports:
       – containerPort: 6379
      
配置v4
redis-master-rc-v4.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: redis-master-rc-v4  #升级的不能和v2一样
  labels:
    names: redis-master-lb-4 #升级的不能和v2一样
spec:
  replicas: 4
  selector:
    name: redis-master-lb-4 #升级的不能和v2一样
  template:
    metadata:
      labels:
        name: redis-master-lb-4  #升级的不能和v2一样
    spec:
     containers:
     – name: master
       image: kubeguide/redis-master:latest  #升级的不能和v2一样
       ports:
       – containerPort: 6379

———–配置方式2------------
配置文件v2
redis-master-rc-v2.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: redis-master-rc-v2  #升级的不能一样
  labels:
    names: redis-master-lb  
    ver: v1                 #建rc的时候这个就要存在,否则后面升级会报错
spec:
  replicas: 2
  selector:
    name: redis-master-lb
    ver: v1                #建rc的时候这个就要存在,否则后面升级会报错

  template:
    metadata:
      labels:
        name: redis-master-lb-2
        ver: v1            #建rc的时候这个就要存在,否则后面升级会报错

    spec:
     containers:
     – name: master
       image: kubeguide/redis-master:1.0  #升级的不能一样
       ports:
       – containerPort: 6379
      
配置v4
redis-master-rc-v4.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: redis-master-rc-v4 
  labels:
    names: redis-master-lb-4
    ver: v2                #这个原来的版本就要存在,本次要不一样,否则升级会报错
spec:
  replicas: 4
  selector:
    name: redis-master-lb
    ver: v2                #这个原来的版本就要存在,本次要不一样,否则升级会报错

  template:
    metadata:
      labels:
        name: redis-master-lb
        ver: v2                #这个原来的版本就要存在,本次要不一样,否则升级会报错
    spec:
     containers:
     – name: master
       image: kubeguide/redis-master:latest  #升级的不能和v2一样
       ports:
       – containerPort: 6379

 

————-升级有误 进行回滚 kubectl rolling-update RC名 –image=镜像 –rollback
[root@k8s-master redis_rolling]# kubectl rolling-update redis-master-rc-v2 –image=kubeguide/redis-master:1.0 –rollback
Command "rolling-update" is deprecated, use "rollout" instead
error: Don’t specify –filename or –image on rollback
See ‘kubectl rolling-update -h’ for help and examples.
[root@k8s-master redis_rolling]#

升级正常就不能用这种方式进行回滚

———–报错
[root@k8s-master yaml]# kubectl rolling-update redis-master-rc -f redis-master-rc-v2.yaml
Command "rolling-update" is deprecated, use "rollout" instead
error: redis-master-rc-v2.yaml contains a /v1, Kind=ReplicationController not a ReplicationController
问题和解决方法看 配置方式2------------

报错2
[root@k8s-master redis_rolling]# kubectl rolling-update redis-master-rc-v2 -f redis-master-rc-v3.yaml
Command "rolling-update" is deprecated, use "rollout" instead
error: redis-master-rc-v3.yaml must specify a matching key with non-equal value in Selector for redis-master-rc-v2
[root@k8s-master redis_rolling]# !v
说明
must specify a matching key with non-equal value in Selector for redis-master-rc-v2
这里报错说明是配置文件的问题,
 
问题和解决方法看 配置方式2------------

k8s pod模版

No Comments Kubernetes

pod模版

apiVersion: v1                  #必选,版本号,例如v1,版本号必须可以用 kubectl api-versions 查询到 .
kind: Pod                #必选,Pod
metadata:                #必选,元数据
  name: string                  #必选,Pod名称
  namespace: string             #必选,Pod所属的命名空间,默认为"default"
  labels:                 #自定义标签
    – name: string                #自定义标签名字
  annotations:                         #自定义注释列表
    – name: string
spec:                     #必选,Pod中容器的详细定义
  containers:                   #必选,Pod中容器列表
  – name: string                      #必选,容器名称,需符合RFC 1035规范
    image: string                     #必选,容器的镜像名称
    imagePullPolicy: [ Always|Never|IfNotPresent ]  #获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像,否则下载镜像,Nerver表示仅使用本地镜像
    command: [string]             #容器的启动命令列表,如不指定,使用打包时使用的启动命令
    args: [string]                   #容器的启动命令参数列表
    workingDir: string                     #容器的工作目录
    volumeMounts:             #挂载到容器内部的存储卷配置
    – name: string              #引用pod定义的共享存储卷的名称,需用volumes[]部分定义的的卷名
      mountPath: string                 #存储卷在容器内mount的绝对路径,应少于512字符
      readOnly: boolean                 #是否为只读模式
    ports:                #需要暴露的端口库号列表
    – name: string              #端口的名称
      containerPort: int                #容器需要监听的端口号
      hostPort: int                  #容器所在主机需要监听的端口号,默认与Container相同
      protocol: string                  #端口协议,支持TCP和UDP,默认TCP
    env:                    #容器运行前需设置的环境变量列表
    – name: string                  #环境变量名称
      value: string                 #环境变量的值
    resources:                        #资源限制和请求的设置
      limits:                   #资源限制的设置
        cpu: string                 #Cpu的限制,单位为core数,将用于docker run –cpu-shares参数
        memory: string                  #内存限制,单位可以为Mib/Gib,将用于docker run –memory参数
      requests:                       #资源请求的设置
        cpu: string                 #Cpu请求,容器启动的初始可用数量
        memory: string                    #内存请求,容器启动的初始可用数量
    livenessProbe:                  #对Pod内各容器健康检查的设置,当探测无响应几次后将自动重启该容器,检查方法有exec、httpGet和tcpSocket,对一个容器只需设置其中一种方法即可
      exec:               #对Pod容器内检查方式设置为exec方式
        command: [string]               #exec方式需要制定的命令或脚本
      httpGet:                #对Pod内个容器健康检查方法设置为HttpGet,需要制定Path、port
        path: string
        port: number
        host: string
        scheme: string
        HttpHeaders:
        – name: string
          value: string
      tcpSocket:      #对Pod内个容器健康检查方式设置为tcpSocket方式
         port: number
       initialDelaySeconds: 0       #容器启动完成后首次探测的时间,单位为秒
       timeoutSeconds: 0        #对容器健康检查探测等待响应的超时时间,单位秒,默认1秒
       periodSeconds: 0         #对容器监控检查的定期探测时间设置,单位秒,默认10秒一次
       successThreshold: 0
       failureThreshold: 0
       securityContext:
         privileged: false
    restartPolicy: [Always | Never | OnFailure] #Pod的重启策略,Always表示一旦不管以何种方式终止运行,kubelet都将重启,OnFailure表示只有Pod以非0退出码退出才重启,Nerver表示不再重启该Pod
    nodeSelector: obeject       #设置NodeSelector表示将该Pod调度到包含这个label的node上,以key:value的格式指定
    imagePullSecrets:     #Pull镜像时使用的secret名称,以key:secretkey格式指定
    – name: string
    hostNetwork: false          #是否使用主机网络模式,默认为false,如果设置为true,表示使用宿主机网络
    volumes:            #在该pod上定义共享存储卷列表
    – name: string         #共享存储卷名称 (volumes类型有很多种)
      emptyDir: {}          #类型为emtyDir的存储卷,与Pod同生命周期的一个临时目录。为空值
      hostPath: string          #类型为hostPath的存储卷,表示挂载Pod所在宿主机的目录
        path: string              #Pod所在宿主机的目录,将被用于同期中mount的目录
      secret:           #类型为secret的存储卷,挂载集群与定义的secre对象到容器内部
        scretname: string 
        items:    
        – key: string
          path: string
      configMap:                  #类型为configMap的存储卷,挂载预定义的configMap对象到容器内部
        name: string
        items:
        – key: string
          path: string

一看必会系列:k8s 练习3 pod 的扩容和缩减

No Comments Kubernetes

pod 的扩容和缩减

[root@k8s-master yaml]# kubectl get rc
NAME              DESIRED   CURRENT   READY   AGE
frontend-rc       3         3         3       18h
redis-master-rc   1         1         1       35h
redis-slave-rc    2         2         2       35h
[root@k8s-master yaml]# kubectl scale rc frontend-rc –replicas=4
replicationcontroller/frontend-rc scaled
[root@k8s-master yaml]# kubectl get rc
NAME              DESIRED   CURRENT   READY   AGE
frontend-rc       4         4         4       18h
redis-master-rc   1         1         1       35h
redis-slave-rc    2         2         2       35h
[root@k8s-master yaml]# kubectl get rc,pod
NAME                                    DESIRED   CURRENT   READY   AGE
replicationcontroller/frontend-rc       4         4         4       18h
replicationcontroller/redis-master-rc   1         1         1       35h
replicationcontroller/redis-slave-rc    2         2         2       35h

NAME                        READY   STATUS    RESTARTS   AGE
pod/frontend-rc-2h62f       1/1     Running   0          18h
pod/frontend-rc-5dwk2       1/1     Running   0          18h
pod/frontend-rc-dmxp8       1/1     Running   0          18h
pod/frontend-rc-flg9m       1/1     Running   0          9s
pod/redis-master-rc-jrrgx   1/1     Running   0          35h
pod/redis-slave-rc-f9svq    1/1     Running   0          23h
pod/redis-slave-rc-p6kbq    1/1     Running   0          35h
[root@k8s-master yaml]#

 

[root@k8s-master yaml]# kubectl scale rc frontend-rc –replicas=2
replicationcontroller/frontend-rc scaled
[root@k8s-master yaml]#
[root@k8s-master yaml]#
[root@k8s-master yaml]# kubectl get rc,pod
NAME                                    DESIRED   CURRENT   READY   AGE
replicationcontroller/frontend-rc       2         2         2       18h
replicationcontroller/redis-master-rc   1         1         1       35h
replicationcontroller/redis-slave-rc    2         2         2       35h

NAME                        READY   STATUS    RESTARTS   AGE
pod/frontend-rc-5dwk2       1/1     Running   0          18h
pod/frontend-rc-dmxp8       1/1     Running   0          18h
pod/redis-master-rc-jrrgx   1/1     Running   0          35h
pod/redis-slave-rc-f9svq    1/1     Running   0          23h
pod/redis-slave-rc-p6kbq    1/1     Running   0          35h
[root@k8s-master yaml]#
[root@k8s-master yaml]#

[root@k8s-master hpa]# kubectl autoscale rc hpa-apache-rc –min=1 –max=10 –cpu-percent=50
horizontalpodautoscaler.autoscaling/hpa-apache-rc autoscaled
[root@k8s-master hpa]# kubectl get rc,hpa
NAME                                    DESIRED   CURRENT   READY   AGE
replicationcontroller/frontend-rc       2         2         2       21h
replicationcontroller/hpa-apache-rc     1         1         1       113m
replicationcontroller/redis-master-rc   1         1         1       37h
replicationcontroller/redis-slave-rc    2         2         2       37h

NAME                                                REFERENCE                             TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
horizontalpodautoscaler.autoscaling/hpa-apache-rc   ReplicationController/hpa-apache-rc   <unknown>/50%   1         10        0          5s
[root@k8s-master hpa]#

进bosybox进行测试
[root@k8s-master hpa]# kubectl exec -it busybox-pod sh

/ # while true; do wget -q -O-  http://hpa-apache-svc > /dev/null;done

[root@k8s-master ~]# kubectl get rc,hpa
NAME                                    DESIRED   CURRENT   READY   AGE
replicationcontroller/frontend-rc       2         2         2       21h
replicationcontroller/hpa-apache-rc     3         3         3       128m
replicationcontroller/redis-master-rc   1         1         1       38h
replicationcontroller/redis-slave-rc    2         2         2       37h

NAME                                                REFERENCE                             TARGETS    MINPODS   MAXPODS   REPLICAS   AGE
horizontalpodautoscaler.autoscaling/hpa-apache-rc   ReplicationController/hpa-apache-rc   122%/50%   1         10        3          15m
[root@k8s-master ~]#

稳定在 3个POD CPU恢得到44%
[root@k8s-master ~]# kubectl get rc,hpa
NAME                                    DESIRED   CURRENT   READY   AGE
replicationcontroller/frontend-rc       2         2         2       21h
replicationcontroller/hpa-apache-rc     3         3         3       148m
replicationcontroller/redis-master-rc   1         1         1       38h
replicationcontroller/redis-slave-rc    2         2         2       38h

NAME                                                REFERENCE                             TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
horizontalpodautoscaler.autoscaling/hpa-apache-rc   ReplicationController/hpa-apache-rc   44%/50%   1         10        3          35m
[root@k8s-master ~]#

退出测试后过段时间,pod恢复成一个
[root@k8s-master hpa]# kubectl get rc,hpa,svc
NAME                                    DESIRED   CURRENT   READY   AGE
replicationcontroller/hpa-apache-rc     1         1         1       159m

NAME                                                REFERENCE                             TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
horizontalpodautoscaler.autoscaling/hpa-apache-rc   ReplicationController/hpa-apache-rc   0%/50%    1         10        1          45m

NAME                     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
service/hpa-apache-svc   ClusterIP   10.100.27.38     <none>        80/TCP         157m

使用yaml的方式进行autoscale

[root@k8s-master hpa]# kubectl create -f hpa-apache-autoscale.yaml
horizontalpodautoscaler.autoscaling/hpa-apache-autoscale created
[root@k8s-master hpa]# kubectl get hpa
NAME                   REFERENCE                                        TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
hpa-apache-autoscale   ReplicationController/hpa-apache-autoscale-pod   <unknown>/50%   1         10        0          9s
[root@k8s-master hpa]#
刚启动时  出现<unknown> 不过不要紧,过段时间就好了。

[root@k8s-master ~]# kubectl get hpa    #现在已读到CPU信息
NAME                   REFERENCE                             TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
hpa-apache-autoscale   ReplicationController/hpa-apache-rc   0%/50%    1         10        1          53s

继续测试
[root@k8s-master hpa]# kubectl exec -it busybox-pod sh
#这里地址用的service的名字   http://service 当然也可以用IP加端口的方式
/ # while true;do wget -q -O-  http://hpa-apache-svc > /dev/null;done

CPU上来了且生成到了3个POD来解决问题
[root@k8s-master ~]# kubectl get hpa
NAME                   REFERENCE                             TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
hpa-apache-autoscale   ReplicationController/hpa-apache-rc   44%/50%   1         10        3          4m48s

 

删除autoscale
[root@k8s-master hpa]# kubectl get hpa
NAME            REFERENCE                             TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
hpa-apache-rc   ReplicationController/hpa-apache-rc   0%/50%    1         10        1          51m

[root@k8s-master hpa]# kubectl delete hpa hpa-apache-rc
horizontalpodautoscaler.autoscaling "hpa-apache-rc" deleted

[root@k8s-master hpa]# kubectl get hpa
No resources found.
[root@k8s-master hpa]#

配置文件如下
[root@k8s-master hpa]# tree .
.
├── busybox-pod.yaml
├── hpa-apache-autoscale.yaml
├── hpa-apache-rc.yaml
└── hpa-apache-svc.yaml

├── busybox-pod.yaml
apiVersion: v1                                                                             
kind: Pod
metadata:                                                                                  
  name: busybox-pod                                                                  
spec:                                                                                      
  containers:
    – name: busybox
      image: busybox
      command: [ "sleep" , "3600"]
     
├── hpa-apache-autoscale.yaml

apiVersion: autoscaling/v1                                                                     
kind: HorizontalPodAutoscaler
metadata:                                                                                  
  name: hpa-apache-autoscale                                                                      
spec:                                                                                      
  scaleTargetRef:
    apiVersion: v1
    kind: ReplicationController
    name: hpa-apache-rc                                                 
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50
 
├── hpa-apache-rc.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: hpa-apache-rc
spec:
  replicas: 1
  template:
    metadata:
      name: hpa-apache-lb
      labels:
        name: hpa-apache-lb
    spec:
     containers:
     – name: hpa-apache-ctn
       image:  reg.ccie.wang/test/ubuntu:apache2.4.29
       resources:
         requests:
           cpu: 200m
       ports:
       – containerPort: 80
      
└── hpa-apache-svc.yaml
apiVersion: v1                                                                             
kind: Service
metadata:                                                                                  
  name: hpa-apache-svc                                                                       
spec:                                                                                      
  ports:
    – port: 80

Kubernetes(k8s) EmptyDir、HostPath、ConfigMap和Secret等几种存储类型介绍

No Comments Kubernetes

一个运行中的容器,缺省情况下,对文件系统的写入,都是发生在其分层文件系统的可写层的,一旦容器运行结束,所有写入都会被丢弃。因此需要对持久化支持。

Kubernetes 中通过 Volume 的方式提供对存储的支持。下面对一些常见的存储概念进行一点简要的说明。

EmptyDir

顾名思义,EmptyDir是一个空目录,他的生命周期和所属的 Pod 是完全一致的,可能读者会奇怪,那还要他做什么?EmptyDir的用处是,可以在同一 Pod 内的不同容器之间共享工作过程中产生的文件。

缺省情况下,EmptyDir 是使用主机磁盘进行存储的,也可以设置emptyDir.medium 字段的值为Memory,来提高运行速度,但是这种设置,对该卷的占用会消耗容器的内存份额。

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  – image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    – mountPath: /cache
      name: cache-volume
  volumes:
  – name: cache-volume
    emptyDir: {}
HostPath

这种会把宿主机上的指定卷加载到容器之中,当然,如果 Pod 发生跨主机的重建,其内容就难保证了。

这种卷一般和DaemonSet搭配使用,用来操作主机文件,例如进行日志采集的 FLK 中的 FluentD 就采用这种方式,加载主机的容器日志目录,达到收集本主机所有日志的目的。

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  – image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    – mountPath: /test-pd
      name: test-volume
  volumes:
  – name: test-volume
    hostPath:
      # directory location on host
      path: /data
NFS/GlusterFS/CephFS/AWS/GCE 等等

作为一个容器集群,支持网络存储自然是重中之重了,Kubernetes 支持为数众多的云提供商和网络存储方案。

各种支持的方式不尽相同,例如 GlusterFS 需要创建 Endpoint,Ceph/NFS 之流就没这么麻烦了。

各种个性配置可移步参考文档。

ConfigMap 和 Secret

镜像使用的过程中,经常需要利用配置文件、启动脚本等方式来影响容器的运行方式,如果仅有少量配置,我们可以使用环境变量的方式来进行配置。然而对于一些较为复杂的配置,例如 Apache 之类,就很难用这种方式进行控制了。另外一些敏感信息暴露在 YAML 中也是不合适的。

ConfigMap 和 Secret 除了使用文件方式进行应用之外,还有其他的应用方式;这里仅就文件方式做一点说明。

例如下面的 ConfigMap,将一个存储在 ConfigMap 中的配置目录加载到卷中。

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    – name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "ls /etc/config/" ]
      volumeMounts:
      – name: config-volume
        mountPath: /etc/config
  volumes:
    – name: config-volume
      configMap:
        # Provide the name of the ConfigMap containing the files you want
        # to add to the container
        name: special-config
  restartPolicy: Never
注意,这里的 ConfigMap 会映射为一个目录,ConfigMap 的 Key 就是文件名,每个 Value 就是文件内容,比如下面命令用一个目录创建一个 ConfigMap:

kubectl create configmap \
    game-config \
    –from-file=docs/user-guide/configmap/kubectl
创建一个 Secret:

kubectl create secret generic \
    db-user-pass –from-file=./username.txt \
    –from-file=./password.txt
使用 Volume 加载 Secret:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  namespace: myns
spec:
  containers:
    – name: mypod
      image: redis
      volumeMounts:
        – name: foo
          mountPath: /etc/foo
          readOnly: true
  volumes:
    – name: foo
      secret:
        secretName: mysecret
可以看到 Secret 和 ConfigMap 的创建和使用是很相似的。在 RBAC 中,Secret 和 ConfigMap 可以进行分别赋权,以此限定操作人员的可见、可控权限。

PV & PVC

PersistentVolume 和 PersistentVolumeClaim 提供了对存储支持的抽象,也提供了基础设施和应用之间的分界,管理员创建一系列的 PV 提供存储,然后为应用提供 PVC,应用程序仅需要加载一个 PVC,就可以进行访问。

而 1.5 之后又提供了 PV 的动态供应。可以不经 PV 步骤直接创建 PVC。

原文出处:fleeto -> http://blog.fleeto.us/content/kubernetes-zhong-de-ji-chong-cun-chu

Kubernetes部分Volume类型介绍及yaml示例–emptyDir

No Comments Kubernetes

Kubernetes部分Volume类型介绍及yaml示例–emptyDir(本地数据卷)

说明
EmptyDir类型的volume创建于pod被调度到某个宿主机上的时候,而同一个pod内的容器都能读写EmptyDir中的同一个文件。一旦这个pod离开了这个宿主机,EmptyDir中的数据就会被永久删除。所以目前EmptyDir类型的volume主要用作临时空间,比如Web服务器写日志或者tmp文件需要的临时目录。
实战使用共享卷的标准单容器POD
#创建yaml文件
cat >> emptyDir.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
    labels:
        name: test-emptypath
        role: master
    name: test-emptypath
    namespace: test
spec:
    containers:
        – name: test-emptypath
            image: nginx:1.7.9
            volumeMounts:
             – name: log-storage
                 mountPath: /tmp/
    volumes:
    – name: log-storage
        emptyDir: {}
#启动emptyDir.yaml
kubectl create -f ./emptyDir.yaml
#查看Pod运行状态
kubectl get po -n test
NAME                         READY     STATUS    RESTARTS   AGE
test-emptypath               1/1       Running   0          3h
##说明:当 Pod 被分配给节点时,首先创建 emptyDir 卷,并且只要该 Pod
##在该节点上运行,该卷就会存在。正如卷的名字所述,它最初是空的。
实战使用共享卷的标准多容器POD、
#创建yaml文件
cat  >> emptyDir2.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
    name: datagrand
    namespace: test
spec:
    containers:
    – name: test1
        image: nginx:1.7.9
        volumeMounts:
        – name: log-storage
            mountPath: /usr/share/nginx/html
    – name: test2
        image: centos
        volumeMounts:
        – name: log-storage
            mountPath: /html
        command: ["/bin/sh","-c"]
        args:
            – while true;do
                    data >> /html/index.html;
                    sleep 1;
                done
volumes:
    – name: log-storage
        emptyDir: {}
##说明:在这个例子中,我们定义了一个名为HTML的卷。它的类型是emptyDir,
##这意味着当一个POD被分配到一个节点时,卷先被创建,并只要Pod在节点上
##运行时,这个卷仍存在。正如名字所说,它最初是空的。第一容器运行nginx的
##服务器并将共享卷挂载到目录/ usr /share/ nginx /html。第二容器使用centos
##的镜像,并将共享卷挂载到目录/HTML。每一秒,第二容器添加当前日期和时
##间到index.html文件中,它位于共享卷。当用户发出一个HTTP请求到POD,
##nginx的服务器读取该文件并将其传递给响应请求的用户。
#运行yaml
kubectl create -f ./emptyDir2.yaml
#查看Pod运行状态
kubectl get po -n test
NAME                         READY     STATUS    RESTARTS   AGE
datagrand                    2/2       Running   0          22m
#进入容器test1
kubectl exec -it datagrand -c test1 /bin/bash -n test
root@datagrand:/# cd /usr/share/nginx/html
root@datagrand:/usr/share/nginx/html# ls
index.html
##添加内容
root@datagrand:/usr/share/nginx/html# echo "this is a test" >> index.html
#进入容器test2
kubectl exec -it datagrand -c test2 /bin/bash -n test
[root@datagrand /]# cd html
[root@datagrand html]# ls
index.html
[root@datagrand html]# cat index.html
this is a test
##emptyDir卷是两个容器(test1和test2)共享的
参考文档
https://www.kubernetes.org.cn/2767.html

Kubernetes部分Volume类型介绍及yaml示例–emptyDir

No Comments 网络技术

Kubernetes部分Volume类型介绍及yaml示例–emptyDir(本地数据卷)

说明
EmptyDir类型的volume创建于pod被调度到某个宿主机上的时候,而同一个pod内的容器都能读写EmptyDir中的同一个文件。一旦这个pod离开了这个宿主机,EmptyDir中的数据就会被永久删除。所以目前EmptyDir类型的volume主要用作临时空间,比如Web服务器写日志或者tmp文件需要的临时目录。
实战使用共享卷的标准单容器POD
#创建yaml文件
cat >> emptyDir.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
    labels:
        name: test-emptypath
        role: master
    name: test-emptypath
    namespace: test
spec:
    containers:
        – name: test-emptypath
            image: nginx:1.7.9
            volumeMounts:
             – name: log-storage
                 mountPath: /tmp/
    volumes:
    – name: log-storage
        emptyDir: {}
#启动emptyDir.yaml
kubectl create -f ./emptyDir.yaml
#查看Pod运行状态
kubectl get po -n test
NAME                         READY     STATUS    RESTARTS   AGE
test-emptypath               1/1       Running   0          3h
##说明:当 Pod 被分配给节点时,首先创建 emptyDir 卷,并且只要该 Pod
##在该节点上运行,该卷就会存在。正如卷的名字所述,它最初是空的。
实战使用共享卷的标准多容器POD、
#创建yaml文件
cat  >> emptyDir2.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
    name: datagrand
    namespace: test
spec:
    containers:
    – name: test1
        image: nginx:1.7.9
        volumeMounts:
        – name: log-storage
            mountPath: /usr/share/nginx/html
    – name: test2
        image: centos
        volumeMounts:
        – name: log-storage
            mountPath: /html
        command: ["/bin/sh","-c"]
        args:
            – while true;do
                    data >> /html/index.html;
                    sleep 1;
                done
volumes:
    – name: log-storage
        emptyDir: {}
##说明:在这个例子中,我们定义了一个名为HTML的卷。它的类型是emptyDir,
##这意味着当一个POD被分配到一个节点时,卷先被创建,并只要Pod在节点上
##运行时,这个卷仍存在。正如名字所说,它最初是空的。第一容器运行nginx的
##服务器并将共享卷挂载到目录/ usr /share/ nginx /html。第二容器使用centos
##的镜像,并将共享卷挂载到目录/HTML。每一秒,第二容器添加当前日期和时
##间到index.html文件中,它位于共享卷。当用户发出一个HTTP请求到POD,
##nginx的服务器读取该文件并将其传递给响应请求的用户。
#运行yaml
kubectl create -f ./emptyDir2.yaml
#查看Pod运行状态
kubectl get po -n test
NAME                         READY     STATUS    RESTARTS   AGE
datagrand                    2/2       Running   0          22m
#进入容器test1
kubectl exec -it datagrand -c test1 /bin/bash -n test
root@datagrand:/# cd /usr/share/nginx/html
root@datagrand:/usr/share/nginx/html# ls
index.html
##添加内容
root@datagrand:/usr/share/nginx/html# echo "this is a test" >> index.html
#进入容器test2
kubectl exec -it datagrand -c test2 /bin/bash -n test
[root@datagrand /]# cd html
[root@datagrand html]# ls
index.html
[root@datagrand html]# cat index.html
this is a test
##emptyDir卷是两个容器(test1和test2)共享的
参考文档
https://www.kubernetes.org.cn/2767.html

Cephfs & Ceph RBD 在k8s中的适用场景讨论及数据库性能压测

No Comments Kubernetes

 

测试发现cephfs的小文件读写性能一般,且写入延迟偏高,性能不甚满意,但是满足于日常应用环境的读写是没有问题的,但是在面对数据库的应用场景,是否能满足性能要求呢?本篇主要结合kubernetes,针对数据库应用场景,对cephfs 和 ceph rbd这两种ceph存储接口来进行性能对比测试.

 

适用场景讨论
Cephfs:
优点:
1.读取延迟低,I/O带宽表现良好,尤其是block size较大一些的文件
2.灵活度高,支持k8s的所有接入模式
缺点:
1.写入延迟相对较高且延迟时间不稳定
适用场景:
适用于要求灵活度高(支持k8s多节点挂载特性),对I/O延迟不甚敏感的文件读写操作,以及非海量的小文件存储支持.例如作为常用的应用/中间件挂载存储后端.

Ceph RBD:
优点:
1.I/O带宽表现良好
2.读写延迟都很低
3.支持镜像快照,镜像转储
缺点:
1.不支持多节点挂载
适用场景:
对I/O带宽和延迟要求都较高,且无多个节点同时读写数据需求的应用,例如数据库.

测试方法可参考上方链接中的文章,这里直接贴结果:

结果分析:

ssd raid性能毫无疑问是最好的
ceph rbd 数据库qps/tps可达ssd raid的60%-70%,
cephfs因为写入延迟不稳定的原因,压测过程中极小比例的操作响应时间非常漫长,导致qps/tps值整体表现不佳
hdd测试得到的qps/tps值中规中矩,操作最低响应时间较其他三者要高,但最高响应时间值也不会很高.然而机械硬盘介质决定了随着它的负载增高寻址时间会随之加长,性能将会呈线性下降.
———————
作者:ywq935
来源:CSDN
原文:https://blog.csdn.net/ywq935/article/details/82895732
版权声明:本文为博主原创文章,转载请附上博文链接!

一看必会系列:docker 实战14 docker国内镜像加速推荐

No Comments Docker

 

用了很多源,这个飞一样的速度,注意要注册帐号。

 

https://www.daocloud.io/mirror#accelerator-doc

 

配置 Docker 加速器
Linux
curl -sSL https://get.daocloud.io/daotools/set_mirror.sh | sh -s http://f1361db2.m.daocloud.io
该脚本可以将 –registry-mirror 加入到你的 Docker 配置文件 /etc/docker/daemon.json 中。适用于 Ubuntu14.04、Debian、CentOS6 、CentOS7、Fedora、Arch Linux、openSUSE Leap 42.1,其他版本可能有细微不同。更多详情请访问文档。

macOS
Docker For Mac

右键点击桌面顶栏的 docker 图标,选择 Preferences ,在 Daemon 标签(Docker 17.03 之前版本为 Advanced 标签)下的 Registry mirrors 列表中加入下面的镜像地址:

http://f1361db2.m.daocloud.io
点击 Apply & Restart 按钮使设置生效。

Docker Toolbox 等配置方法请参考帮助文档。

Windows
Docker For Windows

在桌面右下角状态栏中右键 docker 图标,修改在 Docker Daemon 标签页中的 json ,把下面的地址:

http://f1361db2.m.daocloud.io
加到" registry-mirrors"的数组里。点击 Apply 。

Docker Toolbox 等配置方法请参考帮助文档。