一篇文章搞懂K8S高级特性

目录
  • K8S高级特性
  • 高级特性
  • 总结
  • kubectl排查服务问题
  • K8S真的放弃Docker了吗?

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的内容:

下载地址(不需要积分):下载地址

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的底层使用。

到此这篇关于K8S高级特性的文章就介绍到这了,更多相关K8S高级特性内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • Kubernetes(k8s)基础介绍

    之前我一直想学习Kubernetes,因为它听起来很有意思(如果你是希腊人,你会觉得这个名字很有问题),但我从来没有机会,因为我没有任何东西需要运行在集群中.而最近,我的工作中开始逐步涉及Kubernetes相关的事情,所以这次我抓住机会,开始查资料,但后来我发现目前所有的资料(包括官方教程)都过于冗长,结构也不合理,这让我一开始有点沮丧. 经过几天的研究,我开始逐步理解Kubernetes的核心理念,并且把他部署到了生产环境中.因为我的简历现在说自己是个"Kubernetes专家",

  • Docker学习笔记之k8s部署方法

    本文记录了如何在ubuntu 14.04裸机上部署k8s集群,参考自官方文档. 拓扑结构 1master + 2minion k8s-master 192.168.0.201 master k8s-node1 192.168.0.202 minion k8s-node2 192.168.0.203 minion 准备工作系统 安装Ubuntu 14.04 LTS 64bit server版本系统,配置好hostname和ip. 在更新国内的软件源的时候,由于GFW的原因,经常会出现md5校验错误

  • 一篇文章搞懂K8S高级特性

    目录 K8S高级特性 高级特性 总结 kubectl排查服务问题 K8S真的放弃Docker了吗? K8S高级特性 K8S中还有一些高级特性有必要了解下,比如弹性扩缩应用(见上文).滚动更新(见上文).配置管理.存储卷.网关路由等. 在了解这些高级特性之前有必要先看几个K8S的核心概念: ReplicaSet ReplicaSet确保任何时间都有指定数量的Pod副本在运行.通常用来保证给定数量的.完全相同的Pod的可用性.建议使用Deployment来管理ReplicaSet,而不是直接使用.

  • 一篇文章搞懂JavaScript正则表达式之方法

    咱们来看看JavaScript中都有哪些操作正则的方法. RegExp RegExp 是正则表达式的构造函数. 使用构造函数创建正则表达式有多种写法: new RegExp('abc'); // /abc/ new RegExp('abc', 'gi'); // /abc/gi new RegExp(/abc/gi); // /abc/gi new RegExp(/abc/m, 'gi'); // /abc/gi 它接受两个参数:第一个参数是匹配模式,可以是字符串也可以是正则表达式:第二个参数是

  • 一篇文章搞懂python的转义字符及用法

    什么是转义字符 转义字符是一个计算机专业词汇.在计算机当中,我们可以写出123 ,也可以写出字母abcd,但有些字符我们无法手动书写,比如我们需要对字符进行换行处理,但不能写出来换行符,当然我们也看不见换行符.像这种情况,我们需要在字符中使用特殊字符时,就需要用到转义字符,在python里用反斜杠\转义字符. 在交互式解释器中,输出的字符串用引号引起来,特殊字符用反斜杠\转义.虽然可能和输入看上去不太一样,但是两个字符串是相等的. 在python里,转义字符\可以转义很多字符,比如\n表示换行,

  • 一篇文章搞懂Python反斜杠的相关问题

    大家在开发Python的过程中,一定会遇到很多反斜杠的问题,很多人被反斜杠的数量搞得头大. 首先我们写一段非常简单的Python代码,它的作用是把一个字段先转换为JSON格式的字符串,然后把这个字符串再转换为JSON格式的字符串: import json info = {'name': 'kingname', 'address': '杭州', 'salary': 99999} info_json = json.dumps(info) # 第一次转换以后,打印出来 print(info_json)

  • 一篇文章搞懂Python Unittest测试方法的执行顺序

    目录 Unittest 回到主题 源码初窥 回到问题的本质 1. 以字典序的方式编写test方法 2. 回归本质,从根本解决问题 总结 Unittest unittest大家应该都不陌生.它作为一款博主在5-6年前最常用的单元测试框架,现在正被pytest,nose慢慢蚕食. 渐渐地,看到大家更多的讨论的内容从unittest+HTMLTestRunner变为pytest+allure2等后起之秀. 不禁感慨,终究是自己落伍了,跟不上时代的大潮了. 回到主题 感慨完了,回到正文.虽然unitte

  • 一篇文章搞懂MySQL加锁机制

    目录 前言 锁的分类 乐观锁和悲观锁 共享锁(S锁)和排他锁(X锁) 按加锁粒度区分 全局锁 表级锁(表锁和MDL锁) 意向锁 行锁 间隙锁 next-key lock(临键锁) 加锁规则 死锁和死锁检测 总结 前言 在数据库中设计锁的目的是为了处理并发问题,在并发对资源进行访问时,数据库要合理控制对资源的访问规则. 而锁就是用来实现这些访问规则的一个数据结构. 在对数据并发操作时,没有锁可能会引起数据的不一致,导致更新丢失. 锁的分类 乐观锁和悲观锁 乐观锁: 对于出现更新丢失的可能性比较乐观

  • 一篇文章搞懂Go语言中的Context

    目录 0 前置知识sync.WaitGroup 1 简介 2 context.Context引入 3 context包的其他常用函数 3.1 context.Background和context.TODO 3.2 context.WithCancel和 3.3 context.WithTimeout 3.4 context.WithDeadline 3.5 context.WithValue 4 实例:请求浏览器超时 5 Context包都在哪些地方使用 6 小结 0 前置知识sync.Wait

  • 一篇文章搞懂Vue3中如何使用ref获取元素节点

    目录 前言 1.回顾 Vue2 中的 ref 2.Vue3 中 ref 访问元素 3.v-for 中使用 ref 4.ref 绑定函数 5.组件上使用 ref 总结 前言 虽然在 Vue 中不提倡我们直接操作 DOM,毕竟 Vue 的理念是以数据驱动视图.但是在实际情况中,我们有很多需求都是需要直接操作 DOM 节点的,这个时候 Vue 提供了一种方式让我们可以获取 DOM 节点:ref 属性.ref 属性是 Vue2 和 Vue3 中都有的,但是使用方式却不大一样,这也导致了很多从 Vue2

  • 一篇文章搞懂:词法作用域、动态作用域、回调函数及闭包

    前言 把以前一直只限于知道,却不清晰理解的这几个概念完完整整地梳理了一番.内容参考自wiki页面,然后加上自己一些理解. 词法作用域和动态作用域 不管什么语言,我们总要学习作用域(或生命周期)的概念,比如常见的称呼:全局变量.包变量.模块变量.本地变量.局部变量等等.不管如何称呼这些作用域的范围,实现它们的目的都一样: (1)为了避免名称冲突; (2)为了限定变量的生命周期(本文以变量名说事,其它的名称在规则上是一样的). 但是不同语言的作用域规则不一样,虽然学个简单的基础就足够应用,因为我们有

  • python 一篇文章搞懂装饰器所有用法(建议收藏)

    01. 装饰器语法糖 如果你接触 Python 有一段时间了的话,想必你对 @ 符号一定不陌生了,没错 @ 符号就是装饰器的语法糖. 它放在一个函数开始定义的地方,它就像一顶帽子一样戴在这个函数的头上.和这个函数绑定在一起.在我们调用这个函数的时候,第一件事并不是执行这个函数,而是将这个函数做为参数传入它头顶上这顶帽子,这顶帽子我们称之为装饰函数 或 装饰器. 你要问我装饰器可以实现什么功能?我只能说你的脑洞有多大,装饰器就有多强大. 装饰器的使用方法很固定: 先定义一个装饰函数(帽子)(也可以

随机推荐