转载请注明出处:www.huamo.online
字节杭州 求贤若渴:
本文概述了Docker
默认网络的配置,包含了默认创建的网络类型,以及如何创建你自己的用户定义网络。同时也描述了在一台主机或者在一个集群中创建网络所需要的资源。
转载请注明出处:www.huamo.online
字节杭州 求贤若渴:
本文概述了Docker
默认网络的配置,包含了默认创建的网络类型,以及如何创建你自己的用户定义网络。同时也描述了在一台主机或者在一个集群中创建网络所需要的资源。
转载请注明出处:www.huamo.online
字节杭州 求贤若渴:
英文原文: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/
ReplicationController
是什么?一个ReplicationController
可以保证在任一个时刻都有指定数量的pod副本在运行。换句话说,一个ReplicationController
保证了一个或多个相同pod总是运行可用的。如果存在了过多的pod,它会杀掉多余的一些。如果pod数量过少,ReplicationController
会启动更多的pod。不同于手动创建pod,被ReplicationController
维护的pod,如果遇到了宕机,被删除,被终止的情况,都会被自动替换为新的pod。举个例子,你的pod会在破坏性的维护之后被重建,比如内核升级。基于此,我们推荐即使你的应用只需要一个pod,也使用ReplicationController
。你可以把ReplicationController
想象成类似一个进程监控的东西,而不是单独节点上的个别进程,ReplicationController
监督跨越多个节点的多个pod。在讨论中,ReplicationController
常简写为rc
或者rcs
,并且这也是kubectl
命令行中的缩写形式。
转载请注明出处:www.huamo.online
字节杭州 求贤若渴:
有时候,我们在github上看到特别棒的项目,忍不住想要深入的研究,对代码进行一些自己的修改,同时又想保持和本源项目的同步更新,此时就面临着两全的问题:既要有自己的修改,又要有作者的更新。
Git多仓库正好可以解决这个问题,能够在保持修改的同时,追踪本源的更新。下面是解决步骤:
source
,首先,需要在github页面,fork
一份代码。fork
生成的仓库:mine
,将代码clone
到本地:1 | $ git clone mine.git |
push
:1 | $ git add . |
source
有更新,想要将更新运用到mine
仓库中,需要做如下几步操作:首先需要将source
加入到远程仓库列表中,比如取名为upstream
。
1 | $ git remote add upstream source.git //只需做一次 |
每次需要追踪并应用source
更新的时候,都需要在origin/master
分支上做一些操作,当然,如果你想将source
的更新应用到其它分支上,也可以在其它分支上做如下操作。
1 | $ git fetch upstream //从source仓库拉取所有更新 |
转载请注明出处:www.huamo.online
转载请注明出处:www.huamo.online
使用conjure-up
+ juju
+ lxd
部署的kubernetes
集群,如果需要修改master
或者worker
上的服务运行配置,知道以下几点将会很有帮助。
$SNAP_DATA指的就是
/var/snap/...
路径所有的服务配置都在节点系统中的
/var/snap/$app/.../args
文件中修改完配置后,直接
reboot
重启节点系统,就会使改变生效
例如,在初始部署的时候,集群的--allow-privileged
没有设置为true
,在实际使用中,发现需要容器特权,此时就需要修改服务配置。
解决方法
worker
节点的kubelet
运行参数,使其--allow-privileged true
。master
节点的kube-apiserver
运行参数,使其--allow-privileged true
步骤
juju status
查看集群状态信息,有类似下文的输出1 | Unit Workload Agent Machine Public address Ports Message |
juju ssh 6
进入kuberneter-worker/0
节点中
修改worker
节点的kubelet
运行参数
1 | sudo -s |
master
节点的kube-apiserver
运行参数1 | juju ssh 5 |
转载请注明出处:www.huamo.online
'
具有raw字符串的功能,即被单引号'
包含的字符串,维持字面意思,其中的$
这种特殊字符都不会被解析。1 | test@runningday ~$echo '$PATH' |
curl
发送POST请求时,-d
后的json数据,如果含有字符串,必须使用双引号"
包裹,不能使用单引号'
,否则会返回错误码。1 | test@runningday ~$curl -H "Content-Type: application/json" -d "{'app_key': 'key1', 'app_secret': 'secret1'}" https:/open.c.163.com/api/v1/token |
key1
,secret1
使用变量引用的方式,我们就要注意到上文的2个问题,小心谨慎的拼装出最后的命令。$
能够被正确解析为变量引用,所以-d
的数据整体也要用双引号包裹,而内部需要使用\
来进行转义1 | test@runningday ~$api_prefix="https://open.c.163.com" |
shadowsocks
1 | pip install shadowsocks |
shadowsocks
配置文件1 | vim /home/test/ss-config.json |
shadowsocks
服务1 | sslocal -c /home/test/ss-config.json //前端运行 |
1 | export all_proxy=socks5://127.0.0.1:1080 |
以下流程在
minikube
中完全跑通
docker registry
registry
支持TLS验证,并且TLS证书支持IP验证【默认只支持域名验证】registry
不仅可以被集群中pod
访问,而且可以被集群外部访问。registry
使用的存储基于NFS,这就意味着你可以将镜像存在网络中其它主机上。仓库的首要任务就是存储数据。我们需要决定将数据存储在哪里,可以使用Kubernetes的PersistentVolume
对象实现持久化。
1 | # kube-registry-pv.yaml |
这里面使用nfs作为持久化挂载,关于如何搭建NFS服务器,可以查看我的这篇文章:Linux NFS使用 。
PV持久卷创建完毕后,我们可以使用PersistentVolumeClaim
来绑定这个PV。
1 | # kube-registry-pvc.yaml |
现在我们可以创建一个Docker仓库了。
1 | # kube-registry-rc.yaml |
这里面使用了hostPort: 5000
将Pod中的仓库端口映射到minikube的5000
端口中,以便集群外部也能访问这个docker registry。
并且,我们通过使用名叫registry-tls-secret
的Secret
资源,为这个registry pod提供了TLS必要的server.crt
和server.key
。这个Secrets
以及证书相关,会在下文介绍。
我们可以将registry Pod作为一个Service
暴露出来。
1 | # kube-registry-svc.yaml |
OK,目前为止,我们已经建立了docker registry的相关资源,接下来就是准备TLS支持的相关工作。
这一段走的时候不太顺利,尝试了很多方法,也解决了很多问题,大致包括:
IP SANs
错误cannot validate certificate for 192.168.1.100 because it doesn't contain any IP SANs
。custom root CA
目录下,如果采用自签名证书,或者不提供CA,则会报错x509: certificate signed by unknown authority
。如前所述,我们将registry服务映射到了minikube的5000
端口上,假设minikube的IP地址为192.168.99.100
,根据这些信息我们来生成192.168.99.100:5000
服务端TLS证书。
当然了,如果你是土豪,可以直接到公网CA上直接买证书,就可以跳过这一段辛酸的经验
IP SANs
问题为了让证书支持IP验证,我们首先需要定制一个自己的openssl模板文件,创建文件openssl.cnf
,内容如下:
1 | [ req ] |
主要是subjectAltName = IP:192.168.99.100
这句话,开启了对IP的验证功能。
ca.key
1 | openssl genrsa -out ca.key 2048 |
openssl.cnf
生成ca.crt
1 | openssl req -x509 -new -nodes -key ca.key -subj "/CN=192.168.99.100:5000" -days 5000 -config openssl.cnf -out ca.crt |
备注:当然,推荐使用域名作为CN,这样的话,就不需要openssl.cnf文件了,只需要在hosts文件中做域名到IP的映射就行,如果你有公网域名,那就更方便了,连hosts也不用改,DNS服务商已为你做好了一切。
server.key
1 | openssl genrsa -out server.key 2048 |
这个server.key
就是前面ReplicationController
配置文件里面提到的key文件。
openssl.cnf
生成server.csr
1 | openssl req -new -key server.key -subj "/CN=192.168.99.100:5000" -config openssl.cnf -out server.csr |
server.crt
1 | openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 5000 -extensions v3_req -extfile openssl.cnf |
这个命令同时还会生成ca.srl
文件。这个server.crt
就是前面ReplicationController
配置文件里面提到的crt文件。
到这儿,TLS所需要的证书和私钥已经全部准备完毕。
准备好了server.key
和server.crt
,需要提供给registry pod,这样才能提供TLS支持,这里使用kubernetes的Secrets
资源来提供配置。
1 | kubectl --namespace=kube-system create secret generic registry-tls-secret --from-file=server.crt=./server.crt --from-file=server.key=./server.key |
这个Secret
资源名称即为registry-tls-secret
,正好被之前的ReplicationController
所引用。
到这里,所有的准备资源都已就绪,现在需要把它们整合起来并运行。首先看下当前的目录结构:
1 | . |
创建文件start.sh
,这样便于随时自动化启动运行:
1 | kubectl --namespace=kube-system create secret generic registry-tls-secret --from-file=server.crt=./server.crt --from-file=server.key=./server.key |
创建文件delete.sh
,便于自动化关闭服务:
1 | kubectl --namespace=kube-system delete secrets registry-tls-secret |
将一切运行起来:
1 | sh ./delete.sh /*删除所有相关资源以初始化*/ |
我们可以在能访问192.168.99.100
的任一台机器上验证这一切,在验证之前,还有一项准备工作要做,否则docker会提示你证书无效:x509: certificate signed by unknown authority
1 | sudo mkdir -p /etc/docker/certs.d/192.168.99.100:5000 |
1 | docker pull busybox |
以下过程在
Ubuntu 16.04
裸机上完全跑通
本文展示了在Ubuntu 16.04
系统上搭建Kubernetes集群的方法,用到了Canonical Kubernetes的发行版本,这是一种快捷搭建本地Kubernetes集群的方法,并能够支持动态增删node节点。
主要搭建步骤是,使用conjure-up
工具,结合juju
,基于LXD
搭建Kubernetes集群,并使用kubelet
和kube-proxy
将其他机器作为node节点,注册入该集群中。
以下为详细步骤(最好已经翻墙)