前文我们聊到了k8s中给Pod添加存储卷相关话题,回顾请参考:https://www.cnblogs.com/qiuhom-1874/p/14180752.html;今天我们来聊一下持久存储卷相关话题;

  volume的基础使用,需要我们用户手动来向不同类型存储接口传递不同的参数,从而实现把外部存储映射到k8s上的一个volume对象,使得pod才能正常的挂载对应的存储卷,对应pod里的容器才能正常使用;这种使用方式的前提是用户必须了解对应的存储系统,了解对应类型的存储接口,以及相关参数;这使得用户在k8s上使用存储卷变得有些复杂;为了简化这一过程,在k8s上使用pv和pvc资源来把对应底层存储接口给隐藏了,用户使用存储卷不再关心底层存储系统接口;不管底层是那种类型的存储,用户只需面对一个pvc接口即可;

  PV、PVC和K8s集群以及pod的关系

  提示:用户在创建pod时使用存储卷只需要关心对应名称空间的pvc对象;而对应pv是需要集群管理管理员定义;后端存储是专门的存储管理员负责管理;pv是k8s上的一种标准资源,全称叫做PersistentVolume翻译成中文就是持久存储卷;它主要作用是把后端存储中的某个逻辑单元,映射为k8s上的pv资源;pv是集群级别的资源;任意名称空间都可以直接关联某一个pv;关联pv的过程我们叫做绑定pv;而对应名称空间关联某一pv需要使用pvc资源来定义;pvc全称PersistentVolumeClaim的缩写,意思就是持久存储卷申请;在一个名称空间下创建一个pvc就是把对应名称空间同集群上的某一pv做绑定;一旦一个名称空间绑定了一个pv后,对应的pv就会从available状态转变成bond状态,其他名称空间将不能再使用,只有对应pv是available状态才能正常的被其他名称空间关联绑定;简单讲pvc和pv的关系是一一对应的,一个pv只能对应一个pvc;至于同一名称空间下的多个pod是否能够同时使用一个PVC取决pv是否允许多路读写,对应pv是否支持多路读写取决后端存储系统;不同类型的存储系统,对应访问模式也有所不同。访问模式有三种,单路读写(ReadWriteOnce简称RWO),多路读写(ReadWriteMany简称RWX),多路只读(ReadOnlyMany简称ROX);

  示例:pv资源创建

[root@master01 ~]# cat pv-v1-demo.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv-v1
labels:
storsystem: nfs-v1
rel: stable
spec:
capacity:
storage: 1Gi
volumeMode: Filesystem
accessModes: ["ReadWriteOnce","ReadWriteMany","ReadOnlyMany"]
persistentVolumeReclaimPolicy: Retain
mountOptions:
- hard
- nfsvers=4.1
nfs:
path: /data/v1
server: 192.168.0.99
[root@master01 ~]#

  提示:pv是k8s的标准资源,其群组版本为v1,类型为PersistentVolume;spec.capacity.storage字段用来描述pv的存储容量;volumeMode用来描述对应存储系统提供的存储卷类型接口,一般存储卷类型接口有两种,分别是文件系统接口和块设备接口;accessModes用来描述pv的访问模式;presistentVolumeReclaimPolicy字段用来描述存储卷回收策略,持久卷回收策略有3中,一种是Delete,表示当pvc删除以后,对应pv也随之删除;第二种是Recycle,表示当pvc删除以后,对应pv的数据也随之被删除;第三种是Retain表示当pvc被删除以后,pv原封动,即pv也在,对应数据也在;mountOptions字段用来指定挂载选项;nfs表示后端存储为nfs,对于不同类型的存储,对应的要传递的参数各不相同,对于nfs这种类型的存储,我们只需要指定其nfs服务器地址以及对应共享出来的文件路径;以上配置就表示把nfs上的/data/v1目录映射到k8s上的pv,对应pv的名称为nfs-pv-v1;这里需要注意一点,在创建pv时,对应后端存储应该提前准备好;

  应用配置清单

[root@master01 ~]# kubectl apply -f pv-v1-demo.yaml
persistentvolume/nfs-pv-v1 created
[root@master01 ~]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
nfs-pv-v1 1Gi RWO,ROX,RWX Retain Available 4s
[root@master01 ~]# kubectl describe pv nfs-pv-v1
Name: nfs-pv-v1
Labels: rel=stable
storsystem=nfs-v1
Annotations: <none>
Finalizers: [kubernetes.io/pv-protection]
StorageClass:
Status: Available
Claim:
Reclaim Policy: Retain
Access Modes: RWO,ROX,RWX
VolumeMode: Filesystem
Capacity: 1Gi
Node Affinity: <none>
Message:
Source:
Type: NFS (an NFS mount that lasts the lifetime of a pod)
Server: 192.168.0.99
Path: /data/v1
ReadOnly: false
Events: <none>
[root@master01 ~]#

  提示:在pv的详细信息中能够看到,当前pv的状态为available,pv对应后端的存储是nfs,对应存储的ip地址为192.168.0.99,当前pv对应后端存储的逻辑单元就是/data/v1;

  示例:创建pvc

[root@master01 ~]# cat pvc-v1-demo.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-nfs-pv-v1
namespace: default
labels:
storsystem: nfs-v1
spec:
accessModes:
- ReadWriteMany
volumeMode: Filesystem
resources:
requests:
storage: 500Mi
selector:
matchLabels:
storsystem: nfs-v1
rel: stable
[root@master01 ~]#

  提示:pvc也是k8s上的标准资源,对应的群组版本为v1,类型为PersistentVolumeClaim;其中spec.accessModes字段是用来指定其pvc的访问模式,一般这个模式是被pv的accessModes包含,也就说pvc的访问模式必须是pv的子集,即等于小于pv的访问模式;resources用来描述对应pvc的存储空间限制,requests用来描述对应pvc最小容量限制,limits用来描述最大容量限制;selector用来定义标签选择器,主要作用过滤符合对应标签的pv;如果不定义标签选择器,它会在所有available状态的pv中,通过其容量大小限制以及访问模式去匹配一个最佳的pv进行关联;

  应用配置清单

[root@master01 ~]# kubectl apply -f pvc-v1-demo.yaml
persistentvolumeclaim/pvc-nfs-pv-v1 created
[root@master01 ~]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-nfs-pv-v1 Bound nfs-pv-v1 1Gi RWO,ROX,RWX 8s
[root@master01 ~]# kubectl describe pvc pvc-nfs-pv-v1
Name: pvc-nfs-pv-v1
Namespace: default
StorageClass:
Status: Bound
Volume: nfs-pv-v1
Labels: storsystem=nfs-v1
Annotations: pv.kubernetes.io/bind-completed: yes
pv.kubernetes.io/bound-by-controller: yes
Finalizers: [kubernetes.io/pvc-protection]
Capacity: 1Gi
Access Modes: RWO,ROX,RWX
VolumeMode: Filesystem
Used By: <none>
Events: <none>
[root@master01 ~]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
nfs-pv-v1 1Gi RWO,ROX,RWX Retain Bound default/pvc-nfs-pv-v1 19m
[root@master01 ~]#

  提示:这里显示pvc的大小是pvc最大容量显示,默认不限制最大容量就是其pv的最大容量;从上面的显示可以看到对应pv被pvc绑定以后,其状态就变成了bound;

  示例:创建pod关联pvc,并在其pod容器里挂载pvc

[root@master01 ~]# cat redis-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: redis-demo
labels:
app: redis
spec:
containers:
- name: redis
image: redis:alpine
volumeMounts:
- mountPath: /data
name: redis-data
volumes:
- name: redis-data
persistentVolumeClaim:
claimName: pvc-nfs-pv-v1
[root@master01 ~]#

  提示:在pod里关联pvc,只需要指定后端存储类型为persistentVolumeClaim,然后指定对应的pvc名称;

  应用资源清单

[root@master01 ~]# kubectl apply -f redis-demo.yaml
pod/redis-demo created
[root@master01 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
redis-demo 0/1 ContainerCreating 0 7s
[root@master01 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
redis-demo 1/1 Running 0 27s
[root@master01 ~]# kubectl describe pod redis-demo
Name: redis-demo
Namespace: default
Priority: 0
Node: node03.k8s.org/192.168.0.46
Start Time: Fri, 25 Dec 2020 21:55:41 +0800
Labels: app=redis
Annotations: <none>
Status: Running
IP: 10.244.3.105
IPs:
IP: 10.244.3.105
Containers:
redis:
Container ID: docker://8e8965f52fd0144f8d6ce68185209114163a42f8437d7d845d431614f3d6dd05
Image: redis:alpine
Image ID: docker-pullable://redis@sha256:68d4030e07912c418332ba6fdab4ac69f0293d9b1daaed4f1f77bdeb0a5eb048
Port: <none>
Host Port: <none>
State: Running
Started: Fri, 25 Dec 2020 21:55:48 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/data from redis-data (rw)
/var/run/secrets/kubernetes.io/serviceaccount from default-token-xvd4c (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
redis-data:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: pvc-nfs-pv-v1
ReadOnly: false
default-token-xvd4c:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-xvd4c
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 37s default-scheduler Successfully assigned default/redis-demo to node03.k8s.org
Normal Pulling 36s kubelet Pulling image "redis:alpine"
Normal Pulled 30s kubelet Successfully pulled image "redis:alpine" in 5.284107704s
Normal Created 30s kubelet Created container redis
Normal Started 30s kubelet Started container redis
[root@master01 ~]#

  提示:可以看到对应pod已经正常运行起来;从详细信息中可以看到对应pod使用的volumes类型为PersistentVolumeClaim,对应名称为pvc-nfs-pv-v1;对应容器以读写方式挂载了对应存储卷;

  测试:在redis-demo上产生数据,看看是否能够正常保存到nfs服务器上?

[root@master01 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
redis-demo 1/1 Running 0 5m28s
[root@master01 ~]# kubectl exec -it redis-demo -- /bin/sh
/data # redis-cli
127.0.0.1:6379> set mykey "this is test key "
OK
127.0.0.1:6379> get mykey
"this is test key "
127.0.0.1:6379> BGSAVE
Background saving started
127.0.0.1:6379> exit
/data # ls
dump.rdb
/data #

  在nfs服务器上查看对应目录下是否有dump.rdb文件产生?

[root@docker_registry ~]# ll /data/v1
total 4
-rw-r--r-- 1 polkitd qiuhom 122 Dec 25 22:02 dump.rdb
[root@docker_registry ~]#

  提示:可以看到,redis上产生的快照文件在nfs服务器上有对应的文件存在;

  测试:删除pod,看看对应文件是否还在?

[root@master01 ~]# kubectl delete -f redis-demo.yaml
pod "redis-demo" deleted
[root@master01 ~]# kubectl get pods
No resources found in default namespace.
[root@master01 ~]# ssh 192.168.0.99
The authenticity of host '192.168.0.99 (192.168.0.99)' can't be established.
ECDSA key fingerprint is SHA256:hQoossQnTJMXB0+DxJdTt6DMHuPFLDd5084tHyJ7920.
ECDSA key fingerprint is MD5:ef:61:b6:ee:76:46:9d:0e:38:b6:b5:dd:11:66:23:26.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.99' (ECDSA) to the list of known hosts.
root@192.168.0.99's password:
Last login: Fri Dec 25 20:13:05 2020 from 192.168.0.232
[root@docker_registry ~]# ll /data/v1
total 4
-rw-r--r-- 1 polkitd qiuhom 122 Dec 25 22:05 dump.rdb
[root@docker_registry ~]# exit
logout
Connection to 192.168.0.99 closed.
[root@master01 ~]#

  提示:可以看到删除了pod对应快照文件在nfs服务器还是存在;

  绑定节点,重新新建pod,看看对应是否能够自动应用快照中的数据?

[root@master01 ~]# cat redis-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: redis-demo
labels:
app: redis
spec:
nodeName: node01.k8s.org
containers:
- name: redis
image: redis:alpine
volumeMounts:
- mountPath: /data
name: redis-data
volumes:
- name: redis-data
persistentVolumeClaim:
claimName: pvc-nfs-pv-v1
[root@master01 ~]# kubectl apply -f redis-demo.yaml
pod/redis-demo created
[root@master01 ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
redis-demo 0/1 ContainerCreating 0 8s <none> node01.k8s.org <none> <none>
[root@master01 ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
redis-demo 1/1 Running 0 21s 10.244.1.88 node01.k8s.org <none> <none>
[root@master01 ~]#

  提示:可以看到新建的pod被调度到node01上了;

  进入对应pod,看看是否应用了其快照文件中的数据?对应key是否能够被应用到内存?

[root@master01 ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
redis-demo 1/1 Running 0 2m39s
[root@master01 ~]# kubectl exec -it redis-demo -- /bin/sh
/data # redis-cli
127.0.0.1:6379> get mykey
"this is test key "
127.0.0.1:6379> exit
/data # ls
dump.rdb
/data # exit
[root@master01 ~]#

  提示:可以看到新建的pod能够正常读取到nfs上的快照文件并应用到内存中;

  删除pvc,看看对应pv是否被删除?

  提示:可以看到在没有删除pod的情况下,对应删除操作被阻塞了;

  查看pvc状态

[root@master01 ~]# kubectl delete pvc pvc-nfs-pv-v1
persistentvolumeclaim "pvc-nfs-pv-v1" deleted
^C
[root@master01 ~]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-nfs-pv-v1 Terminating nfs-pv-v1 1Gi RWO,ROX,RWX 34m
[root@master01 ~]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-nfs-pv-v1 Terminating nfs-pv-v1 1Gi RWO,ROX,RWX 34m
[root@master01 ~]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-nfs-pv-v1 Terminating nfs-pv-v1 1Gi RWO,ROX,RWX 34m
[root@master01 ~]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
nfs-pv-v1 1Gi RWO,ROX,RWX Retain Bound default/pvc-nfs-pv-v1 52m
[root@master01 ~]#

  提示:可以看到现在pvc的状态变成了terminating,但对应pvc还在并没有被删除;对应pv还处于绑定状态;

  删除pod,看看对应pvc是否会被删除呢?

[root@master01 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
redis-demo 1/1 Running 0 14m
[root@master01 ~]# kubectl delete pod redis-demo
pod "redis-demo" deleted
[root@master01 ~]# kubectl get pvc
No resources found in default namespace.
[root@master01 ~]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
nfs-pv-v1 1Gi RWO,ROX,RWX Retain Released default/pvc-nfs-pv-v1 54m
[root@master01 ~]#

  提示:可以看到删除对应pod以后,pvc就立即删除了;对应pvc被删除以后,对应pv的状态就从bound状态转变为Released状态,表示等待回收;我们在资源清单中使用的是Retain回收策略,pv和pvc都是我们人工手动回收;

  删除pv,看看对应数据是否会被删除?

[root@master01 ~]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
nfs-pv-v1 1Gi RWO,ROX,RWX Retain Released default/pvc-nfs-pv-v1 57m
[root@master01 ~]# kubectl delete pv nfs-pv-v1
persistentvolume "nfs-pv-v1" deleted
[root@master01 ~]# kubectl get pv
No resources found
[root@master01 ~]# ssh 192.168.0.99
root@192.168.0.99's password:
Last login: Fri Dec 25 22:05:53 2020 from 192.168.0.41
[root@docker_registry ~]# ll /data/v1
total 4
-rw-r--r-- 1 polkitd qiuhom 122 Dec 25 22:24 dump.rdb
[root@docker_registry ~]# exit
logout
Connection to 192.168.0.99 closed.
[root@master01 ~]#

  提示:可以看到删除了pv,对应快照文件并没有清除;

  以上就是pv和pvc资源的用法,下面我们再来说一下sc资源

  SC是StorageClass的缩写,表示存储类;这种资源主要用来对pv资源的自动供给提供接口;所谓自动供给是指用户无需手动创建pv,在使用pvc时自动创建pv并关联到对应pv上;使用sc资源的前提是对应后端存储必须支持rustfull类型接口的管理接口,并且指定pvc必须是在对应存储类;简单讲SC资源就是用来为后端存储提供自动创建pv的接口;如下图

  提示:使用sc动态创建pv,对应pvc必须也是属于对应的sc;上图主要描述了用户在创建pvc时,应用对应的sc以后,对应sc会调用底层存储系统的管理接口,创建对应的pv并关联至对应pvc;

  示例:创建sc资源

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: slow
provisioner: kubernetes.io/glusterfs
parameters:
resturl: "http://127.0.0.1:8081"
clusterid: "630372ccdc720a92c681fb928f27b53f"
restauthenabled: "true"
restuser: "admin"
secretNamespace: "default"
secretName: "heketi-secret"
gidMin: "40000"
gidMax: "50000"
volumetype: "replicate:3"

  提示:上述是官方文档中的一个示例,在创建sc资源时,对应群组是storage.k8s.io/v1,类型为StorageClass;provisioner字段用于描述对应供给接口名称;parameters用来定义向对应存储管理接口要传递的参数;

  在pvc资源中引用SC资源对象

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: foo-pvc
namespace: foo
spec:
storageClassName: "slow"
volumeName: foo-pv
...

  提示:在创建pvc时用storageClassName字段来指定对应的SC即可;

容器编排系统K8s之PV、PVC、SC资源的更多相关文章

  1. 容器编排系统K8s之ConfigMap、Secret资源

    前文我们了解了k8s上的pv/pvc/sc资源的使用和相关说明,回顾请参考:https://www.cnblogs.com/qiuhom-1874/p/14188621.html:今天我们主要来聊一下 ...

  2. 容器编排系统K8s之StatefulSet控制器

    前文我们聊到了k8s的configmap和secret资源的说明和相关使用示例,回顾请参考:https://www.cnblogs.com/qiuhom-1874/p/14194944.html:今天 ...

  3. 容器编排系统K8s之访问控制--准入控制

    前文我们聊到了k8s的访问控制第二关RBAC授权插件的相关话题,回顾请参考:https://www.cnblogs.com/qiuhom-1874/p/14216634.html:今天我们来聊一下k8 ...

  4. 容器编排系统K8s之访问控制--RBAC授权

    前文我们了解了k8s上的访问控制机制,主要对访问控制中的第一关用户认证做了相关说明以及常规用户的配置文件的制作,回顾请参考:https://www.cnblogs.com/qiuhom-1874/p/ ...

  5. 容器编排系统K8s之访问控制--用户认证

    前文我们聊到了k8s的statefulset控制器相关使用说明,回顾请参考:https://www.cnblogs.com/qiuhom-1874/p/14201103.html:今天我们来聊一下k8 ...

  6. 容器编排系统K8s之flannel网络模型

    前文我们聊到了k8s上webui的安装和相关用户授权,回顾请参考:https://www.cnblogs.com/qiuhom-1874/p/14222930.html:今天我们来聊一聊k8s上的网络 ...

  7. 容器编排系统K8s之Prometheus监控系统+Grafana部署

    前文我们聊到了k8s的apiservice资源结合自定义apiserver扩展原生apiserver功能的相关话题,回顾请参考:https://www.cnblogs.com/qiuhom-1874/ ...

  8. 容器编排系统K8s之Volume的基础使用

    前文我们聊到了k8s上的ingress资源相关话题,回顾请参考:https://www.cnblogs.com/qiuhom-1874/p/14167581.html:今天们来聊一下k8s上volum ...

  9. 容器编排系统K8s之crd资源

    前文我们了解了k8s节点污点和pod的对节点污点容忍度相关话题,回顾请参考:https://www.cnblogs.com/qiuhom-1874/p/14255486.html:今天我们来聊一下扩展 ...

随机推荐

  1. 【mq读书笔记】顺序消息

    注意异常情况导致整个消费无限重试 阻塞消费 mq支持局部消息顺序消费,可以确保同一个消息消费队列中的消息被顺序消费.看下针对顺序消息在整个消费过程中做的调整: 队列负载: DefaultMQPushC ...

  2. Flash----一种VirtualActor模式的分布式有状态系统原型

    首先, 这个Flash不是我们在浏览器用的Flash这种技术, 而是: 动作缓慢, 车速极快------闪电(Flash). 18年的某一个周末, 即兴用Python写了一个Virtual Actor ...

  3. Python学习第四天----模块儿导入

    1.命名空间 模块儿的名字加上文件的名字,就是命名空间. python如何区分一个普通的文件夹和一个包的? 在一个文件夹下有一个特定的文件__init__.py,此时这个文件夹就是一个包.(前后各两个 ...

  4. jvm系列(二)jvm垃圾收集器与内存分配策略

    众所周知,在java语言中,内存分配和回收是由jvm自动管理的.因此内存的分配和回收也是jvm三大功能之一.垃圾收集器(GC)需要完成三件事情: 哪些内存需要回收? 什么时候进行回收? 如何回收? 本 ...

  5. windowsAPI函数操作注册表实现软件开机自启

    注册表的结构 注册表是一个数据库,它的结构同逻辑磁盘类似.注册表包含键(Key),它类似磁盘中的目录,注册表还包含键值(Value),它类似磁盘中的文件.一个键可以包含多个子健和键值,其中键值用于存储 ...

  6. python应用(7):输入与输出

    如前文,流程是程序的主角,而流程一般都需要处理数据,那数据如何进到流程,而最终处理后的数据又如何表现,这就是流程的输入与输出的问题. 本文介绍流程处理的数据的输入与输出. 流程中的输入,一般都会先保存 ...

  7. 大数据开发——Hive笔记

    写在前面 hive是基于Hadoop的一个数据仓库工具,可以将结构化的数据文件映射为一张数据库表,并提供简单的sql查询功能,可以将sql语句转换为MapReduce任务进行运行.Hive的运行原理- ...

  8. 学JAVA的艰难之路

    周五回家了,这两天也没有更新代码系列,很抱歉,之后会补上.今天刚到宿舍,写了会代码,想用一个数组的从键盘输入,再也弄不好了,最终在我不断的翻之前写的代码,终于是找到了一个例子,真的不容易,编程这东西, ...

  9. dart时间处理的几个方法

    一.时间处理的方法 1.获取当前时间 new DateTime.now(); 2.设置时间 new DateTime(2020, 11, 11, 12, 37 , 36); 3.解析时间 DateTi ...

  10. 第5.3节 详说Python风格的函数分配参数

    一.    分配参数的定义 参数收集就是在定义函数时不能确认参数个数,用收集参数将调用时不确定数量的实参存放到收集参数的元组中.分配参数与此过程相反,它不是在定义函数形参时使用星号(1个或2个),而是 ...