多条件模糊查询
select * from t_log where (LOCATE('wu', user_name) > 0 or LOCATE('wu', params ) > 0)and (method='POST' or method='GET');
查询id在列表中的所有结果
select * from t_user where tenant_id in (1,2,3);
yum install nfs-utils
#所有节点,不论NFS服务端还是客户端
systemctl enable rpcbind
systemctl start rpcbind
#NFS服务端
systemctl enable nfs
systemctl start nfs
mkdir /data
chmod 755 /data
vi /etc/exports
/data/ 192.168.0.0/24(rw,sync,no_root_squash,no_all_squash)
systemctl restart nfs
exportfs -r
生效showmount -e localhost
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0003
spec:
capacity: #容量
storage:5Gi
volumeMode: Filesystem #存储卷模式
accessModes: #访问模式
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle #持久化卷回收策略
storageClassName: slow #存储类
mountOptions: #挂接选项
- hard
- nfsvers=4.1
nfs:
path: /data
server: 172.17.0.2
只要资源提供者支持,持久卷能够通过任何方式加载到主机上。每种存储都会有不同的能力,每个PV的访问模式也会被设置成为该卷所支持的特定模式。例如NFS能够支持多个读写客户端,但某个NFS PV可能会在服务器上以只读方式使用。每个PV都有自己的一系列的访问模式,这些访问模式取决于PV的能力。
访问模式的可选范围如下:
在PV中可以指定存储类,通过设置storageClassName
字段进行设置。如果设置了存储类,则此PV只能被绑定到也指定了此存储类的PVC。
当前的回收策略可选值包括:
rm-rf /thevolume/*
)NFS
和HostPath
支持Recycle
策略,AWSEBS、GCE PD支持Delete策略。kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: myclaim
spec:
accessModes: #访问模式
- ReadWriteOnce
volumeMode: Filesystem #存储卷模式
resources: #资源
requests:
storage: 8Gi
storageClassName: slow #存储类
selector: #选择器
matchLabels:
release: "stable"
matchExpressions: #匹配表达式
- {key: environment, operator: In, values: [dev]}
在PVC中,可以通过标签选择器来进一步的过滤PV。仅仅与选择器匹配的PV才会被绑定到PVC中。选择器的组成如下:
matchLabels
: 只有存在与此处的标签一样的PV才会被PVC选中;matchExpressions
:匹配表达式由键、值和操作符组成,操作符包括In
, NotIn
, Exists
和DoesNotExist
,只有符合表达式的PV才能被选择。matchLabels
和matchExpressions
,则会进行求与,即只有同时满足上述匹配要求的PV才会被选择。如果PVC使用storageClassName字段指定一个存储类,那么只有指定了同样的存储类的PV才能被绑定到PVC上。对于PVC来说,存储类并不是必须的。依赖于安装方法,可以在安装过程中使用add-on管理器将默认的StorageClass部署至Kubernetes集群中。当PVC指定了选择器,并且指定了StorageClass,则在匹配PV时,取两者之间的与:即仅仅同时满足存储类和带有要求标签值的PV才能被匹配上。
kind: Pod
apiVersion: v1
metadata:
name: mypod
spec:
containers:
- name: myfrontend
image: dockerfile/nginx
volumeMounts: #挂接存储卷
- mountPath: "/var/www/html" #POD内挂接的路径
name: mypd #所要挂接的存储卷的名称
volumes: #定义存储卷
- name: mypd
persistentVolumeClaim: #所使用的持久化存储卷声明
claimName: myclaim
sudo yum install nfs-utils
sudo systemctl enable rpcbind
sudo systemctl enable nfs
sudo systemctl start rpcbind
sudo systemctl start nfs
sudo mkdir /data
sudo chmod 755 /data
sudo vi /etc/exports
/data/ 192.168.0.0/24(rw,sync,no_root_squash,no_all_squash)
/data
: 共享目录位置。192.168.0.0/24
: 客户端IP
范围,*
代表所有,即没有限制。rw
: 权限设置,可读可写。sync
: 同步共享目录。no_root_squash
: 可以使用root
授权。no_all_squash
: 可以使用普通用户授权。
:wq
保存设置之后,重启 NFS
服务sudo systemctl restart nfs
showmount -e localhost
Export list for localhost:
/data 192.168.0.0/24
从Heapster
的github 中可以看到已经,heapster
已经DEPRECATED
。 这里是heapster
的deprecation timeline。 可以看出heapster
从Kubernetes 1.12
开始从Kubernetes
各种安装脚本中移除。
Kubernetes
推荐使用metrics-server
。我们这里也使用helm
来部署metrics-server
。
metrics-server.yaml
replicaCount: 1
image:
repository: hub.deri.org.cn/k8s/metrics-server-amd64
tag: v0.3.5
pullPolicy: IfNotPresent
args:
- --logtostderr
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP
nodeSelector:
node-role.kubernetes.io/edge: ''
tolerations:
- key: node-role.kubernetes.io/master
operator: Exists
effect: NoSchedule
- key: node-role.kubernetes.io/master
operator: Exists
effect: PreferNoSchedule
helm install stable/metrics-server \
-n metrics-server \
--namespace kube-system \
-f metrics-server.yaml
kubectl top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
node1 650m 32% 1276Mi 73%
node2 73m 3% 527Mi 30%
kubectl top pod -n kube-system
NAME CPU(cores) MEMORY(bytes)
coredns-5c98db65d4-dr8lf 8m 7Mi
coredns-5c98db65d4-lp8dg 6m 8Mi
etcd-node1 44m 46Mi
kube-apiserver-node1 74m 295Mi
kube-controller-manager-node1 35m 50Mi
kube-flannel-ds-amd64-7lwm9 2m 8Mi
kube-flannel-ds-amd64-mm296 5m 9Mi
kube-proxy-7fsrg 1m 11Mi
kube-proxy-k8vhm 3m 11Mi
kube-scheduler-node1 8m 15Mi
kubernetes-dashboard-848b8dd798-c4sc2 2m 14Mi
metrics-server-8456fb6676-fwh2t 10m 19Mi
tiller-deploy-7bf78cdbf7-9q94c 1m 16Mi
遗憾的是,当前
Kubernetes Dashboard
还不支持metrics-server
。因此如果使用metrics-server
替代了heapster
,将无法在dashboard
中以图形展示Pod
的内存和CPU
情况。计划在dashboard 2.0版本以后才会支持,尽情期待~
有时候我们需要在 application.yaml
文件中自定义配置,在程序中通过属性名映射过去,但是有时候定义错误的属性名会导致配置不生效。
属性名不能是is
开头,例如属性名为isLog
,你在配置文件中不管怎么给这个属性设值都不会生效,需要改成log即可。
我使用spring boot
版本:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.6.RELEASE</version>
<relativePath/>
</parent>
概要:要想
k8s
从harbor
中拉取镜像,需要有harbor
的用户、密码、服务器信息,然后在k8s
指定namespace
中创建docker-registry
类型。
前提:已经搭建
K8s
集群、harbor
服务,且已经在机器上配置可以从harbor
中拉取上传镜像。
docker-registry
创建docker-registry
,有两种方式,命令行和YAML
.
kubectl create secret docker-registry test-deri-registry-secret --namespace=test-namespace \
--docker-server=hub.test.org.cn --docker-username=test2019 \
--docker-password=tests12019 --docker-email=admin@harbor.com
需要有一台已经成功登录过harbor
服务器的机器,使用命令cat ~/.docker/config.json
,确认是否有harbor
服务器的认证信息,例如:
{
"auths": {
"hub.test.org.cn:443": {
"auth": "YWRtaW46RGVxasdXXnsada"
}
},
"HttpHeaders": {
"User-Agent": "Docker-Client/19.03.4 (linux)"
}
}
接下来k8s也可以直接使用该认证信息,使用命令cat ~/.docker/config.json |base64 -w 0
将该认证信息BASE64
编码【以下示例结果都是瞎写的,请使用自己返回的结果】。
[root@master ~]# cat .docker/config.json |base64 -w 0
ewoJImF1dGhzIjogewoJCSJodWIuZGVyaS5vcmcuY246NDQzIjogewoJCQkiYXV0aCI6ICJZV1J0YVc0NlJHVnlhU015TURFNSIKCHIUASDGUGDUGAUDUIAGDJIIGIUDZWFkZXJzIjogewoJCSJVc2VyLUFnZW50IjogIkRvY2tlci1DbGllbnQvMTkSDISDhi7asd56523gHGSGH
编写test-registry-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: test-registry-secret
namespace: test-deri
data:
.dockerconfigjson: wraJImF1dGhzIjogeraJCSIxOTIuMTY4LjEzMC4yMyI6IHsKCQkJImF1dGgiOiAiYW5OaVpHVjJaV3h2Y0dWeU9rcHpZakV5TXpRMSIKCQl9Cgl9LAoJIkh0dHBIZWFkZXJzIjogewoJCSJVc2VyLUFnZW50IjogIkRvY2tlci1DbGllbnQvMTguMDkuMiAobGludXgpIgoJfQp9
type: kubernetes.io/dockerconfigjson
使用命令kubectl create -f test-registry-secret.yaml
或者在dashboard
中用上述YAML
即可创建docker-registry
。
使用命令查看结果
kubectl get secret -n test-namespace
kubectl describe secret test-registry-secret -n test-namespace
docker-registry
如何使用刚刚创建的docker-registry
呢?两种方式:
pod
或者deployment
时指定imagePullSecrets
,namespace
的serviceaccount
【默认default
,如果是别的serviceaccount
,需要在创建pod
时指定spec.serviceAccount
】中指定imagePullSecrets
,这样用该serviceaccount
创建的pod
会自动加上。spec:
imagePullSecrets:
- name: test-registry-secret
每次创建pod
时指定secret
,例如
apiVersion: v1
kind: Pod
metadata:
name: test-baresystem
namespace: test-namespace
spec:
containers:
- name: test-baresystem
image: hub.test.org.cn/dev-project/centos6-bare-system:v0
ports:
- containerPort: 8080
hostPort: 30001
imagePullSecrets:
- name: test-registry-secret
以创建namespace
时自动创建的serviceaccount default
为例,首先查看default
的详细情况:
[root@master ~]# kubectl describe sa test-deri -n test-namespace
Name: test-deri
Namespace: test-namespace
Labels: <none>
Annotations: <none>
Image pull secrets: <none>
Mountable secrets: test-deri-token-rmxbn
Tokens: test-deri-token-rmxbn
Events: <none>
可以看到当前的Image pull secrets: <none>
,需要为它指定成刚刚我们创建的secret
。使用命令:
kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "test-registry-secret"}]}' -n test-namespace
或者使用命令:
kubectl edit sa default -n test-namespace
在打开的YAML
文件中添加两行,保存退出。
imagePullSecrets:
- name: test-registry-secret
最后再次查看default
的详细情况,可以看到Image pull secrets: test-registry-secret
.
[root@master ~]# kubectl describe sa default -n test-namespace
Name: default
Namespace: test-namespace
Labels: <none>
Annotations: <none>
Image pull secrets: test-registry-secret
Mountable secrets: default-token-5fcn5
Tokens: default-token-5fcn5
Events: <none>
接下来在test-namespace
命名空间下用default
这个serviceaccount
创建的任何pods
容器,都会自动在pod
定义中附加上下面这样的密钥认证信息了。
最后测试一下吧。