K8S高级特性

K8S中还有一些高级特性有必要了解下,比如弹性扩缩应用(见上文)、滚动更新(见上文)、配置管理、存储卷、网关路由等。
在了解这些高级特性之前有必要先看几个K8S的核心概念:
ReplicaSet
ReplicaSet确保任何时间都有指定数量的Pod副本在运行。通常用来保证给定数量的、完全相同的Pod的可用性。建议使用Deployment来管理ReplicaSet,而不是直接使用。
ConfigMap
ConfigMap是一种API对象,用来将非机密性的数据保存到键值对中。使用时,Pod可以将其用作环境变量、命令行参数或者存储卷中的配置文件。使用ConfigMap可以将你的配置数据和应用程序代码分开。
Volume
Volume指的是存储卷,包含可被Pod中容器访问的数据目录。容器中的文件在磁盘上是临时存放的,当容器崩溃时文件会丢失,同时无法在多个Pod中共享文件,通过使用存储卷可以解决这两个问题。
常用的存储卷有如下几种:

  • configMap:configMap卷提供了向Pod中注入配置数据的方法。ConfigMap对象中存储的数据可以被configMap类型的卷引用,然后被Pod中运行的容器化应用使用。
  • emptyDir:emptyDir卷可用于存储缓存数据。当Pod分派到某个Node上时,emptyDir卷会被创建,并且Pod在该节点上运行期间,卷一直存在。当Pod被从节点上删除时emptyDir卷中的数据也会被永久删除。
  • hostPath:hostPath卷能将主机节点文件系统上的文件或目录挂载到你的Pod中。在Minikube中的主机指的是Minikube所在的虚拟机。
  • local:local卷所代表的是某个挂载的本地设备,例如磁盘、分区或者目录。local卷只能用作静态创建的持久卷,尚不支持动态配置。
  • nfs:nfs卷能将NFS(网络文件系统)挂载到你的Pod中。
  • persistentVolumeClaim:persistentVolumeClaim卷用来将持久卷(PersistentVolume)挂载到Pod中。持久卷(PV)是集群中的一块存储,可以由管理员事先供应,或者使用存储类(Storage Class)来动态供应,持久卷是集群资源类似于节点。

Ingress
Ingress 通过K8S的Ingress资源可以实现类似Nginx的基于域名访问,从而实现Pod的负载均衡访问。
在这里插入图片描述
安装Ingress
进入页面https://github.com/kubernetes/ingress-nginx/blob/nginx-0.20.0/deploy/mandatory.yaml,将里面的内容复制,保存到k8s master机器上的一个文件ingress-controller.yaml里,里面的镜像地址需要修改下,大家直接用下面这个yaml的内容:
csdn完成下载地址(不需要积分):下载地址

apiVersion: v1
kind: Namespace
metadata:
  name: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-configuration
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

kind: ConfigMap
apiVersion: v1
metadata:
  name: tcp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

kind: ConfigMap
apiVersion: v1
metadata:
  name: udp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nginx-ingress-serviceaccount
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: nginx-ingress-clusterrole
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - endpoints
      - nodes
      - pods
      - secrets
    verbs:
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - "extensions"
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
  - apiGroups:
      - "extensions"
    resources:
      - ingresses/status
    verbs:
      - update

---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: nginx-ingress-role
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - pods
      - secrets
      - namespaces
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      # Defaults to "<election-id>-<ingress-class>"
      # Here: "<ingress-controller-leader>-<nginx>"
      # This has to be adapted if you change either parameter
      # when launching the nginx-ingress-controller.
      - "ingress-controller-leader-nginx"
    verbs:
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - endpoints
    verbs:
      - get

---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: nginx-ingress-role-nisa-binding
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: nginx-ingress-role
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx

---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: nginx-ingress-clusterrole-nisa-binding
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: nginx-ingress-clusterrole
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx

---

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/part-of: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
      annotations:
        prometheus.io/port: "10254"
        prometheus.io/scrape: "true"
    spec:
      hostNetwork: true
      serviceAccountName: nginx-ingress-serviceaccount
      containers:
        - name: nginx-ingress-controller
          image: siriuszg/nginx-ingress-controller:0.20.0
          args:
            - /nginx-ingress-controller
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx
            - --annotations-prefix=nginx.ingress.kubernetes.io
          securityContext:
            allowPrivilegeEscalation: true
            capabilities:
              drop:
                - ALL
              add:
                - NET_BIND_SERVICE
            # www-data -> 33
            runAsUser: 33
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          ports:
            - name: http
              containerPort: 80
            - name: https
              containerPort: 443
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1

---

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
spec:
  ports:
    - name: http
      port: 80
      targetPort: 80
      protocol: TCP
    - name: https
      port: 443
      targetPort: 443
      protocol: TCP
  selector:
    app.kubernetes.io/name: default-http-backend
    app.kubernetes.io/part-of: ingress-nginx

---

查看是否安装成功

kubectl get pods -n ingress-nginx -o wide

在这里插入图片描述
配置ingress访问规则(就是类似配置nginx的代理转发配置),让ingress将域名 tomcat.core.com转发给后端的tomcat-service-yaml 服务,新建一个文件ingress- tomcat.yaml,内容如下:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
 name: web-ingress
spec:
 rules:
 - host: tomcat.core.com # 转发域名
   http:
    paths:
    - path: /
      backend: 
       serviceName: tomcat-service-yaml
       servicePort: 80 # service的端口

在这里插入图片描述
查看生效的ingress规则:

kubectl get ing

在这里插入图片描述
在访问机器配置host,master目录:/etc/hosts,在 host里增加如下host(ingress部署的机器ip对应访问的域名)

192.168.159.131 tomcat.core.com
或者
192.168.159.132 tomcat.core.com

配置完后直接在客户机浏览器访问http://tomcat.core.com/ ,能正常访问tomcat。
在这里插入图片描述

高级特性

配置管理

ConfigMap允许你将配置文件与镜像文件分离,以使容器化的应用程序具有可移植性。接下来我们演示下如何将ConfigMap的的属性注入到Pod的环境变量中去。

  • 添加配置文件nginx-config.yaml用于创建ConfigMap,ConfigMap名称为nginx-config,存储信息放在data节点下:
apiVersion: v1
kind: ConfigMap
metadata: 
 name: nginx-config
 namespace: default
data:
 nginx-env: test
  • 应用nginx-config.yaml文件创建ConfigMap:
kubectl create -f nginx-config.yaml
  • 获取所有ConfigMap:
kubectl get configmap

在这里插入图片描述

  • 通过yaml格式查看ConfigMap中的内容:
kubectl get configmaps nginx-config -o yaml

在这里插入图片描述

  • 添加配置文件nginx-deployment.yaml用于创建Deployment,部署一个nginx服务,在Nginx的环境变量中引用ConfigMap中的属性:
apiVersion: apps/v1
kind: Deployment
metadata: 
 name: nginx-deployment
 labels:
  app: nginx
spec:
 replicas: 1
 selector:
  matchLabels:
   app: nginx
 template:
  metadata:
   labels:
    app: nginx
  spec:
   containers:
    - name: nginx
      image: nginx:1.10
      ports:
       - containerPort: 80
      env:
       - name: NGINX_ENV # 在Nginx中设置环境变量
         valueFrom:
          configMapKeyRef:
           name: nginx-config # 设置ConfigMap的名称
           key: nginx-env # 需要取值的键
  • 应用配置文件创建Deployment:
kubectl apply -f nginx-deployment.yaml
  • 创建成功后查看Pod中的环境变量,发现NGINX_ENV变量已经被注入了;
kubectl get pod -o wide

在这里插入图片描述

kubectl exec -it nginx-deployment-5ff74658b6-rlft8 -- sh
# 进入容器控制台执行,下面命令
ECHO $NGINX_ENV
存储卷使用

通过存储卷,我们可以把外部数据挂在到容器中去,供容器中应用访问,这样就算容器崩溃了,数据依然可以存在。

  • 记得之前我们使用Docker部署Nginx的时候,将Nginx的html、logs、conf目录从外部挂载到了容器中;
docker run -p 80:80 --name nginx \
-v /mydata/nginx/html:/usr/share/nginx/html \
-v /mydata/nginx/logs:/var/log/nginx \
-v /mydata/nginx/conf:/etc/nginx \
-d nginx:1.10
  • Minikube 可以认为是一台虚拟机,我们可以用Minikube的ssh命令来访问它
minikube ssh
  • Minikube中默认有一个docker用户,我们先重置下它的密码
sudo passwd docker
  • 在Minikube中创建mydata目录
mkdir /home/docker/mydata
  • 我们需要把nginx的目录复制到Minikube中去,才能实现目录的挂载,注意docker用户只能修改/home/docker目录中的文件,我们通过scp命令来复制文件
scp -r /home/macro/mydata/nginx docker@127.0.0.1:/home/docker/mydata/nginx
  • 添加配置文件nginx-volume-deployment.yaml用于创建Deployment:
apiVersion: apps/v1
kind: Deployment
metadata: 
 name: nginx-volume-deployment
 labels:
  app: nginx
spec:
 replicas: 1
 selector:
  matchLabels:
   app: nginx
 template:
  metadata:
   labels:
    app: nginx
  spec:
   containers:
    - name: nginx
      image: nginx:1.10
      ports:
       - containerPort: 80
      volumeMounts:
       - mountPath: /usr/share/nginx/html
         name: html-volume
       - mountPath: /var/logs/nginx
         name: logs-volume
       - mountPath: /etc/nginx
         name: conf-volume
   volumes:
    - name: html-volume
      hostPath:
       path: /home/docker/mydata/nginx/html
       type: Directory
    - name: logs-volume
      hostPath:
       path: /home/docker/mydata/nginx/logs
       type: Directory
    - name: conf-volume
      hostPath:
       path: /home/docker/mydata/nginx/conf
       type: Directory
  • 应用配置文件创建Deployment
kubectl apply -f nginx-volume-deployment.yaml
  • 添加配置文件nginx-service.yaml用于创建Service
apiVersion: v1
kind: Service
metadata: 
 name: nginx-service
spec:
 type: NodePort
 selector:
  app: nginx
 ports:
 - name: http
    protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 30080
  • 查看下Service服务访问端口
kubectl get services

在这里插入图片描述

  • 通过CURL命令访问Nginx首页信息。
    在这里插入图片描述

总结

Service是K8S服务的核心,屏蔽了服务细节,统一对外暴露服务接口,真正做到了“微服务”。举个例子,我们的一个服务 A,部署了 3 个备份,也就是 3 个 Pod;对于用户来 说,只需要关注一个 Service 的入口就可以,而不需要操心究竟应该请求哪一个 Pod。优 势非常明显:一方面外部用户不需要感知因为 Pod 上服务的意外崩溃、K8S 重新拉起 Pod 而造成的 IP 变更,外部用户也不需要感知因升级、变更服务带来的 Pod 替换而造成的 IP 变化,另一方面,Service 还可以做流量负载均衡。
但是,Service 主要负责 K8S 集群内部的网络拓扑。那么集群外部怎么访问集群内部呢?这个时候就需要 Ingress 了,官方文档中的解释是:
Ingress 是对集群中服务的外部访问进行管理的 API 对象,典型的访问方式是 HTTP。
ngress 可以提供负载均衡、SSL 终结和基于名称的虚拟托管。
翻译一下:Ingress 是整个 K8S 集群的接入层,复杂集群内外通讯。
Ingress 和 Service 的网络拓扑关系图如下:
在这里插入图片描述

kubectl排查服务问题

K8S 上部署服务失败了怎么排查?
用这个命令:

kubectl describe ${RESOURCE} ${NAME}

拉到最后看到Events部分,会显示出 K8S 在部署这个服务过程的关键日志。
一般来说,通过kubectl describe pod ${POD_NAME}已经能定位绝大部分部署失败的问题 了,当然,具体问题还是得具体分析。

K8S 上部署的服务不正常怎么排查?
如果服务部署成功了,且状态为running,那么就需要进入 Pod 内部的容器去查看自己的服 务日志了:
查看 Pod 内部某个 container 打印的日志:

kubectl log ${POD_NAME} ‐c ${CONTAINER_NAME}

进入 Pod 内部某个 container:

kubectl exec ‐it [options] ${POD_NAME} ‐c ${CONTAINER_NAME} [args]

这个命令的作用是通过 kubectl 执行了docker exec xxx进入到容器实例内部。之后,就是 用户检查自己服务的日志来定位问题。

K8S真的放弃Docker了吗?

Docker作为非常流行的容器技术,之前经常有文章说它被K8S弃用了,取而代之的是另一 种容器技术containerd!其实containerd只是从Docker中分离出来的底层容器运行时,使 用起来和Docker并没有啥区别,从Docker转型containerd非常简单,基本没有什么门槛。 只要把之前Docker命令中的docker改为crictl基本就可以了,都是同一个公司出品的东西, 用法都一样。所以不管K8S到底弃用不弃用Docker,对我们开发者使用来说,基本没啥影响!

K8S CRI
K8S发布CRI(Container Runtime Interface),统一了容器运行时接口,凡是支持CRI的 容器运行时,皆可作为K8S的底层容器运行时。
K8S为什么要放弃使用Docker作为容器运行时,而使用containerd呢?
如果你使用Docker作为K8S容器运行时的话,kubelet需要先要通过dockershim去调用 Docker,再通过Docker去调用containerd。
如果你使用containerd作为K8S容器运行时的话,由于containerd内置了CRI插件, kubelet可以直接调用containerd。
使用containerd不仅性能提高了(调用链变短了),而且资源占用也会变小(Docker不是 一个纯粹的容器运行时,具有大量其他功能)。
当然,未来Docker有可能自己直接实现K8S的CRI接口来兼容K8S的底层使用。

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐