Kubernetes(k8s) docker集群搭建
原文地址:https://blog.csdn.net/real_myth/article/details/78719244
一、Kubernetes系列之介绍篇
- 拥有一个唯一指定的名字
- 拥有一个虚拟IP(Cluster IP、Service IP、或VIP)和端口号
- 能够体统某种远程服务能力
- 被映射到了提供这种服务能力的一组容器应用上
- 目标Pod的定义
- 目标Pod需要运行的副本数量(Replicas)
- 要监控的目标Pod标签(Label)
- 每个Node节点都运行着以下一组关键进程
- kubelet:负责对Pod对于的容器的创建、启停等任务
- kube-proxy:实现Kubernetes Service的通信与负载均衡机制的重要组件
- Docker Engine(Docker):Docker引擎,负责本机容器的创建和管理工作
- Cluster IP仅仅作用于Kubernetes Service这个对象,并由Kubernetes管理和分配P地址
- Cluster IP无法被ping,他没有一个“实体网络对象”来响应
- Cluster IP只能结合Service Port组成一个具体的通信端口,单独的Cluster IP不具备通信的基础,并且他们属于Kubernetes集群这样一个封闭的空间。
- 版本标签:"release":"stable","release":"canary"......
- 环境标签:"environment":"dev","environment":"qa","environment":"production"
- 架构标签:"tier":"frontend","tier":"backend","tier":"middleware"
- 分区标签:"partition":"customerA","partition":"customerB"
- 质量管控标签:"track":"daily","track":"weekly"
- kube-Controller进程通过资源对象RC上定义Label Selector来筛选要监控的Pod副本的数量,从而实现副本数量始终符合预期设定的全自动控制流程
- kube-proxy进程通过Service的Label Selector来选择对应的Pod,自动建立起每个Service岛对应Pod的请求转发路由表,从而实现Service的智能负载均衡
- 通过对某些Node定义特定的Label,并且在Pod定义文件中使用Nodeselector这种标签调度策略,kuber-scheduler进程可以实现Pod”定向调度“的特性

Server获取所有的Service信息,并根据Service的信息创建代理服务,实现Service到Pod的请求路由和转发,从而实现Kubernetes层级的虚拟转发网络。
二、基于kubernetes构建Docker集群环境实战
minion上运行的docker拥有不同的ip段,最终目的是使不同minion上正在运行的docker
containner都有一个与别的任意一个containner(别的minion上运行的docker containner)不一样的IP地址。
controller, endpoints controller, namespace controller, and
serviceaccounts controller的循环控制,与kube-apiserver交互,保证这些controller工作

1
2
|
#setenforce 0 #sed -i '/^SELINUX=/cSELINUX=disabled' /etc/sysconfig/selinux |
1
|
# yum -y install etcd kubernetes |
配置etcd。确保列出的这些项都配置正确并且没有被注释掉,下面的配置都是如此
1
2
3
4
5
6
|
#vim /etc/etcd/etcd.conf ETCD_NAME=default ETCD_DATA_DIR= "/var/lib/etcd/default.etcd" ETCD_LISTEN_CLIENT_URLS= "http://0.0.0.0:2379" ETCD_ADVERTISE_CLIENT_URLS= "http://localhost:2379" |
配置kubernetes
1
2
3
4
5
6
7
8
|
vim /etc/kubernetes/apiserver KUBE_API_ADDRESS= "--address=0.0.0.0" KUBE_API_PORT= "--port=8080" KUBELET_PORT= "--kubelet_port=10250" KUBE_ETCD_SERVERS= "--etcd_servers=http://127.0.0.1:2379" KUBE_SERVICE_ADDRESSES= "--service-cluster-ip-range=10.254.0.0/16" KUBE_ADMISSION_CONTROL= "--admission_control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ResourceQuota" KUBE_API_ARGS= "" |
1
|
# for |
3.设置etcd网络
1
|
#etcdctl -C 10.0.0.81:2379 set /atomic.io/network/config '{"Network":"10.1.0.0/16"}' |
1
|
# kubectl get nodes NAME LABELS STATUS |
1
|
# yum -y install flannel kubernetes |
配置kubernetes连接的服务端IP
1
2
3
|
#vim /etc/kubernetes/config KUBE_MASTER= "--master=http://10.0.0.81:8080" KUBE_ETCD_SERVERS= "--etcd_servers=http://10.0.0.81:2379" |
配置kubernetes ,(请使用每台minion自己的IP地址比如10.0.0.81:代替下面的$LOCALIP)
1
2
3
4
5
|
#vim /etc/kubernetes/kubelet<br>KUBELET_ADDRESS="--address=0.0.0.0" KUBELET_PORT= "--port=10250" # change the hostname to this host’s IP address KUBELET_HOSTNAME="--hostname_override=$LOCALIP" KUBELET_API_SERVER= "--api_servers=http://10.0.0.81:8080" KUBELET_ARGS= "" |
1
2
3
4
5
|
# ifconfig docker0 Link encap:Ethernet HWaddr 02:42:B2:75:2E:67 inet addr:172.17.0.1 Bcast:0.0.0.0 Mask:255.255.0.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) |
warning:在运行过docker的机器上可以看到有docker0,这里在启动服务之前需要删掉docker0配置,在命令行运行:sudo ip link delete docker0
3.配置flannel网络
1
2
3
|
#vim /etc/sysconfig/flanneld FLANNEL_ETCD_ENDPOINTS= "http://10.0.0.81:2379" FLANNEL_ETCD_PREFIX= "/atomic.io/network" |
1
|
# for |
1
2
3
4
|
# kubectl get nodes NAME STATUS AGE 10.0.0.82 Ready 1m 10.0.0.83 Ready 1m |
可以看到配置的两台minion已经在master的node列表中了。如果想要更多的node,只需要按照minion的配置,配置更多的机器就可以了。
三、Kubernetes之深入了解Pod
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
|
# yaml格式的pod定义文件完整内容: apiVersion: v1 #必选,版本号,例如v1 kind: Pod #必选,Pod metadata: #必选,元数据 name: string #必选,Pod名称 namespace: string #必选,Pod所属的命名空间 labels: #自定义标签 - name: string #自定义标签名字 annotations: #自定义注释列表 - name: string spec: #必选,Pod中容器的详细定义 containers: #必选,Pod中容器列表 - name: string #必选,容器名称 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 |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
apiVersion:v1 kind: Pod metadata: name: redis-php label: name: redis-php spec: containers: - name: frontend image: kubeguide /guestbook-php-frontend :localredis ports: - containersPort: 80 - name: redis-php image:kubeguide /redis-master ports: - containersPort: 6379 |
1
2
3
|
#kubectl get gods NAME READY STATUS RESTATS AGE redis-php 2 /2 Running 0 10m |
可以看到READY信息为2/2,表示Pod中的两个容器都成功运行了.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
[root@kubernetes-master ~] # kubectl describe redis-php the server doesn't have a resource type "redis-php" [root@kubernetes-master ~] # kubectl describe pod redis-php Name: redis-php Namespace: default Node: kubernetes-minion /10 .0.0.23 Start Time: Wed, 12 Apr 2017 09:14:58 +0800 Labels: name=redis-php Status: Running IP: 10.1.24.2 Controllers: <none> Containers: nginx: Container ID: docker: //d05b743c200dff7cf3b60b7373a45666be2ebb48b7b8b31ce0ece9be4546ce77 Image: nginx Image ID: docker-pullable: //docker .io /nginx @sha256:e6693c20186f837fc393390135d8a598a96a833917917789d63766cab6c59582 Port: 80 /TCP State: Running Started: Wed, 12 Apr 2017 09:19:31 +0800 |
Server进行管理,无法与ReplicationController、Deployment或者DaemonSet进行关联,并且kubelet无法对他们进行健康检查。静态Pod总是由kubelet进行创建,并且总是在kubelet所在的Node上运行。
1
2
3
4
5
|
#kubetctl delete pod static-web-node1 pod "static-web-node1" deleted #kubectl get pods NAME READY STATUS RESTARTS AGE static-web-node1 0 /1 Pending 0 1s |
1
2
|
#rm -f /etc/kubelet.d/static-web.yaml #docker ps |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
apiVersion:v1 kind: Pod metadata: name: redis-php label: name: volume-pod spec: containers: - name: tomcat image: tomcat ports: - containersPort: 8080 volumeMounts: - name: app-logs mountPath: /usr/local/tomcat/logs - name: busybox image:busybox command : [ "sh" , "-C" , "tail ] volumes: - name: app-logs emptyDir:{} |
1
|
#kubectl logs volume-pod -c busybox |
1
|
#kubectl exec -ti volume-pod -c tomcat -- ls /usr/local/tomcat/logs |
v1.2版本开始提供的一种统一集群配置管理方案。
1
2
3
4
5
6
7
8
|
# vim cm-appvars.yaml apiVersion: v1 kind: ConfigMap metadata: name: cm-appvars data: apploglevel: info appdatadir: /var/data |
1
2
|
#kubectl create -f cm-appvars.yaml configmap "cm-appvars.yaml" created |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
#kubectl get configmap NAME DATA AGE cm-appvars 2 3s [root@kubernetes-master ~] # kubectl describe configmap cm-appvars Name: cm-appvars Namespace: default Labels: <none> Annotations: <none> Data ==== appdatadir: 9 bytes apploglevel: 4 bytes [root@kubernetes-master ~] # kubectl get configmap cm-appvars -o yaml apiVersion: v1 data: appdatadir: /var/data apploglevel: info kind: ConfigMap metadata: creationTimestamp: 2017-04-14T06:03:36Z name: cm-appvars namespace: default resourceVersion: "571221" selfLink: /api/v1/namespaces/default/configmaps/cm-appvars uid: 190323cb-20d8-11e7-94ec-000c29ac8d83 |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
apiVersion: v1 kind: ConfigMap metadata: name: cm-appvars data: key-serverxml: <?xml Version= '1.0' encoding= 'utf-8' ?> <Server port= "8005" shutdown = "SHUTDOWN" > ..... < /service > < /Server > key-loggingproperties: "handlers=lcatalina.org.apache.juli.FileHandler, ...." |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
#vim cm-test-app.yaml apiVersion: v1 kind: Pod metadata: name: cm- test -app spec: containers: - name: cm- test -app image: tomcat-app:v1 ports: - containerPort: 8080 volumeMounts: - name: serverxml #引用volume名 mountPath: /configfiles #挂载到容器内部目录 configMap: name: cm- test -appconfigfile #使用configmap定义的的cm-appconfigfile items: - key: key-serverxml #将key=key-serverxml path: server.xml #value将server.xml文件名进行挂载 - key: key-loggingproperties #将key=key-loggingproperties path: logging.properties #value将logging.properties文件名进行挂载 |
1
2
|
#kubectl create -f cm-test-app.yaml Pod "cm-test-app" created |
1
2
3
|
#kubectl exec -ti cm-test-app -- bash root@cm-rest-app:/ # cat /configfiles/server.xml root@cm-rest-app:/ # cat /configfiles/logging.properties |
- configmap必须在pod之间创建
- configmap也可以定义为属于某个Namespace,只有处于相同namespaces中的pod可以引用
- configmap中配额管理还未能实现
- kubelet只支持被api server管理的pod使用configmap,静态pod无法引用
- 在pod对configmap进行挂载操作时,容器内部职能挂载为目录,无法挂载文件。
- RC和DaemonSet:必须设置为Always,需要保证该容器持续运行
- Job:OnFailure或Nerver,确保容器执行完成后不再重启
- kubelet:在Pod失效时重启他,不论RestartPolicy设置什么值,并且也不会对Pod进行健康检查
- LivenessProbe探针:用于判断容器是否存活(running状态),如果LivenessProbe探针探测到容器不健康,则kubelet杀掉该容器,并根据容器的重启策略做响应处理
- ReadinessProbe探针:用于判断容器是否启动完成(ready状态),可以接受请求。如果ReadinessProbe探针探测失败,则Pod的状态被修改。Endpoint
Controller将从service的Endpoint中删除包含该容器所在的Pod的Endpoint。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
apiVersion:v1 kind: Pod metadata: name: liveness- exec label: name: liveness spec: containers: - name: tomcat image: grc.io /google_containers/tomcat args: - /bin/sh - -c - echo ok > /tmp .health; sleep 10; rm -fr /tmp/health ; sleep 600 livenessProbe: exec : command : - cat - /tmp/health initianDelaySeconds:15 timeoutSeconds:1 |
1
2
3
4
5
6
7
8
9
10
11
12
|
kind: Pod metadata: name: pod-with-healthcheck spec: containers: - name: nginx image: nginx livenessProbe: tcpSocket: port: 80 initianDelaySeconds:30 timeoutSeconds:1 |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
apiVersion:v1 kind: Pod metadata: name: pod-with-healthcheck spec: containers: - name: nginx image: nginx livenessProbe: httpGet: path: /_status/healthz port: 80 initianDelaySeconds:30 timeoutSeconds:1 |
- initialDelaySeconds:启动容器后首次监控检查的等待时间,单位秒
- timeouSeconds:健康检查发送请求后等待响应的超时时间,单位秒。当发生超时就被认为容器无法提供服务无,该容器将被重启
Master上的scheduler服务(kube-Scheduler进程)负责实现Pod的调度,整个过程通过一系列复杂的算法,最终为每个Pod计算出一个最佳的目标节点,通常我们无法知道Pod最终会被调度到哪个节点上。实际情况中,我们需要将Pod调度到我们指定的节点上,可以通过Node的标签和pod的nodeSelector属性相匹配来达到目的。
1
|
#kubectllabel nodes k8s-node-1 zonenorth |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
apiVersion:v1 kind: Pod metadata: name: redis-master label: name: redis-master spec: replicas: 1 selector: name: redis-master template: metadata: labels: name: redis-master spec: containers: - name: redis-master images: kubeguide /redis-master ports: - containerPort: 6379 nodeSelector: zone: north |
- 在每个Node上运行个以GlusterFS存储或者ceph存储的daemon进程
- 在每个Node上运行一个日志采集程序,例如fluentd或者logstach
- 在每个Node上运行一个健康程序,采集Node的性能数据。
1
2
3
4
5
6
7
|
#kubectl scale rc redis-slave --replicas=3 ReplicationController "redis-slave" scaled #kubectl get pods NAME READY STATUS RESTARTS AGE redis-slave-1sf23 1 /1 Running 0 1h redis-slave-54wfk 1 /1 Running 0 1h redis-slave-3da5y 1 /1 Running 0 1h |
Podautoscaler(HPA)的控制器,用于实现基于CPU使用路进行启动Pod扩容缩容的功能。该控制器基于Mastger的kube-controller-manager服务启动参数
--horizontal-pod-autoscler-sync-period定义的时长(默认30秒),周期性监控目标Pod的Cpu使用率并在满足条件时对ReplicationController或Deployment中的Pod副本数量进行调整,以符合用户定义的平均Pod
Cpu使用率,Pod Cpu使用率来源于heapster组件,所以需预先安装好heapster。
rolling-update命令一键完成,该命令创建一个新的RC,然后自动控制旧版本的Pod数量逐渐减少到0,同时新的RC中的Pod副本数量从0逐步增加到目标值,最终实现Pod的升级。需要注意的是,系统要求新的RC需要与旧的RC在相同的Namespace内,即不能把别人的资产转到到自家名下。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
apiVersion: v1 kind: replicationController metadata: name: redis-master-v2 labels: name: redis-master Version: v2 spec: replicas: 1 selector: name: redis-master Version: v2 template: labels: name: redis-master Version: v2 spec: containers: - name: master images: kubeguide /redis-master :2.0 ports: - containerPort: 6379 |
需要注意的点:
1
|
#kubectl rolling-update redis-master -f redis-master-controller-v2.yaml |
1
|
#kubectl rolling-update redis-master --image=redis-master:2.0 |
Kubernetes(k8s) docker集群搭建的更多相关文章
- k8s docker集群搭建
一.Kubernetes系列之介绍篇 •Kubernetes介绍 1.背景介绍 云计算飞速发展 - IaaS - PaaS - SaaS Docker技术突飞猛进 - 一次构建,到处运行 - 容器 ...
- .net core i上 K8S(一)集群搭建
1.前言 以前搭建集群都是使用nginx反向代理,但现在我们有了更好的选择——K8S.我不打算一上来就讲K8S的知识点,因为知识点还是比较多,我打算先从搭建K8S集群讲起,我也是在搭建集群的过程中熟悉 ...
- K8S之集群搭建
转自声明 ASP.NET Core on K8S深入学习(1)K8S基础知识与集群搭建 1.K8S环境搭建的几种方式 搭建K8S环境有几种常见的方式如下: (1)Minikube Minikube是一 ...
- centos7上基于kubernetes的docker集群管理
kubernetes和docker的作用这里就不作介绍了,直接进入主题. 本文的目的是搭建docker集群,并使用kubernetes管理它们. 文中的软件环境除了kubernetes和docker, ...
- 基于kubernetes构建Docker集群管理详解-转
http://blog.liuts.com/post/247/ 一.前言 Kubernetes 是Google开源的容器集群管理系统,基于Docker构建一个容器的调度服务,提供资源调度 ...
- 二、基于kubernetes构建Docker集群环境实战
kubernetes是google公司基于docker所做的一个分布式集群,有以下主件组成 etcd: 高可用存储共享配置和服务发现,作为与minion机器上的flannel配套使用,作用是使每台 m ...
- 内网环境上部署k8s+docker集群:集群ftp的yum源配置
接触docker已经有一年了,想把做的时候的一些知识分享给大家. 因为公司机房是内网环境无法连接外网,所以这里所有的部署都是基于内网环境进行的. 首先,需要通过ftp服务制作本地的yum源,可以从ht ...
- hadoop docker集群搭建
获取镜像 #本机内 docker pull ubuntu:16.04 编排镜像 启动一个容器 #本机内 docker run -i -t --name master ubuntu:16.04 在容器内 ...
- docker集群——搭建Mesos+Zookeeper+Marathon的Docker管理平台
服务器架构 机器信息: 这里部属的机器为3个Master控制节点,3个slave运行节点,其中: zookeeper.Mesos-master.marathon运行在Master端:Mesos-sla ...
随机推荐
- [Canvas]英雄可以射箭了
点此下载源码并用浏览器观看. 图例: 代码: <!DOCTYPE html> <html lang="utf-8"> <meta http-equiv ...
- FancyBox-经典的jQuery Lightbox插件
在线演示 本地下载 FancyBox 是一款非常优秀的弹窗插件,能够为图片.HTML内容和其它任务的多媒体内容提供优雅的弹出缩放效果.作为是最流行的 Lightbox 插件之一,可以通过 fitToV ...
- Oracle使用技巧及PL/SQL Developer配置
Oracle使用技巧及PL/SQL Developer配置 摘自:http://livenzhao.spaces.live.com/blog/cns!6E368BE9F6DDD872!595.entr ...
- VS2017安装或卸载错误1303
为添加一个Python开发环境,运行Visual Studio Installer安装报错,下面是日志: 问题日志 安装出现问题. 可通过以下方式排查包故障问题: 1. 使用以下搜索 URL 来搜索针 ...
- asp.net对象合并
public class com { /// <summary> /// 把参数转为JSON字符串 /// </summary> /// <param name=&quo ...
- Ubuntu MYSQL环境搭建
前期准备: 检查系统资源 内存大小 # grep MemTotal/proc/meminfo 检查系统版本 统一为: Ubuntu 12.04.1 LTS(GNU/Linux 3.2.0-29-gen ...
- 第九周(1) Word邮件合并2
第九周(1) Word邮件合并2 教学时间 2013-4-22 教学课时 2 教案序号 15 教学目标 1.进一步掌握邮件合并的技巧和方法.2.利用邮件合并制作准考证.3.掌握在同一页生成多个记录的方 ...
- 动态加载jar包(一)
一.编写被调用的类 package com.qunar.helloworld; public class HelloWorld { public String sayHello(){ return ( ...
- loadrunner -27492超时
- css布局 三栏 自动换行
1.代码实现 <!DOCTYPE html> <html lang="zh"> <head> <meta charset="UT ...