发表于 | 更新于 | 分类于

转载请注明出处：www.huamo.online
字节杭州 求贤若渴：

  1. https://job.toutiao.com/s/JXTdQaH
  2. https://job.toutiao.com/s/JXTMWW3
  3. https://job.toutiao.com/s/JXT1tpC
  4. https://job.toutiao.com/s/JXTdu6h

本文概述了Docker默认网络的配置，包含了默认创建的网络类型，以及如何创建你自己的用户定义网络。同时也描述了在一台主机或者在一个集群中创建网络所需要的资源。

阅读全文 »

发表于 | 更新于 | 分类于

转载请注明出处：www.huamo.online
字节杭州 求贤若渴：

  1. https://job.toutiao.com/s/JXTdQaH
  2. https://job.toutiao.com/s/JXTMWW3
  3. https://job.toutiao.com/s/JXT1tpC
  4. https://job.toutiao.com/s/JXTdu6h

英文原文： 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
字节杭州 求贤若渴：

  1. https://job.toutiao.com/s/JXTdQaH
  2. https://job.toutiao.com/s/JXTMWW3
  3. https://job.toutiao.com/s/JXT1tpC
  4. https://job.toutiao.com/s/JXTdu6h

有时候，我们在github上看到特别棒的项目，忍不住想要深入的研究，对代码进行一些自己的修改，同时又想保持和本源项目的同步更新，此时就面临着两全的问题：既要有自己的修改，又要有作者的更新。

Git多仓库正好可以解决这个问题，能够在保持修改的同时，追踪本源的更新。下面是解决步骤：

  • 假如有本源项目仓库：source，首先，需要在github页面，fork一份代码。

Alt text

  • 对于fork生成的仓库：mine，将代码clone到本地：
1
$ git clone mine.git
  • 本地做一些自己的修改，保持修改很简单，就是普通的push：
1
2
3
$ git add .
$ git commit -m "commit my change"
$ git push origin master
  • 如果本源仓库source有更新，想要将更新运用到mine仓库中，需要做如下几步操作：

  1. 首先需要将source加入到远程仓库列表中，比如取名为upstream。

    1
    $ git remote add upstream source.git //只需做一次

  2. 每次需要追踪并应用source更新的时候，都需要在origin/master分支上做一些操作，当然，如果你想将source的更新应用到其它分支上，也可以在其它分支上做如下操作。

    1
    2
    3
    4
    5
    $ git fetch upstream //从source仓库拉取所有更新
    $ git merge upstream/master //将更新合并到origin/master上
    $ git add . //merge时可能会冲突，解决完所有冲突，使用add消除MERGIG状态
    $ git commit -m "track source update"
    $ git push origin master //将应用后的更新提交到mine仓库

转载请注明出处：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，在实际使用中，发现需要容器特权，此时就需要修改服务配置。

解决方法

  1. 需要修改所有worker节点的kubelet运行参数，使其--allow-privileged true。
  2. 同时，需要修改master节点的kube-apiserver运行参数，使其--allow-privileged true

步骤

  • juju status查看集群状态信息，有类似下文的输出
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Unit                      Workload  Agent  Machine  Public address  Ports           Message
easyrsa/0*                active    idle   0        10.0.8.3                        Certificate Authority connected.
etcd/0*                   active    idle   1        10.0.8.203      2379/tcp        Healthy with 3 known peers
etcd/1                    active    idle   2        10.0.8.14       2379/tcp        Healthy with 3 known peers
etcd/2                    active    idle   3        10.0.8.133      2379/tcp        Healthy with 3 known peers
kubeapi-load-balancer/0*  active    idle   4        10.0.8.234      443/tcp         Loadbalancer ready.
kubernetes-master/0*      waiting   idle   5        10.0.8.77       6443/tcp        Waiting for kube-system pods to start
  flannel/0*              active    idle            10.0.8.77                       Flannel subnet 10.1.66.1/24
kubernetes-worker/0       active    idle   6        10.0.8.240      80/tcp,443/tcp  Kubernetes worker running.
  flannel/3               active    idle            10.0.8.240                      Flannel subnet 10.1.84.1/24
kubernetes-worker/1*      active    idle   7        10.0.8.138      80/tcp,443/tcp  Kubernetes worker running.
  flannel/2               active    idle            10.0.8.138                      Flannel subnet 10.1.16.1/24
kubernetes-worker/2       active    idle   8        10.0.8.139      80/tcp,443/tcp  Kubernetes worker running.
  flannel/1               active    idle            10.0.8.139                      Flannel subnet 10.1.46.1/24

  • juju ssh 6 进入kuberneter-worker/0节点中

  • 修改worker节点的kubelet运行参数

1
2
3
4
5
sudo -s
vim /var/snap/kubelet/27/args
添加一行后保存退出： --allow-privileged true
reboot 
//改完配置后，直接reboot重启系统，即可使worker节点修改生效。
  • 同样的方式，修改master节点的kube-apiserver运行参数
1
2
3
4
5
juju ssh 5
sudo -s
vim /var/snap/kube-apiserver/27/args
添加一行后保存退出： --allow-privileged true
reboot //重启master节点使改变生效
  • 这样，整个集群就支持容器特权了。OKay！

转载请注明出处：www.huamo.online

发表于 | 更新于 | 分类于
  • Bash中的单引号'具有raw字符串的功能，即被单引号'包含的字符串，维持字面意思，其中的$这种特殊字符都不会被解析。
1
2
3
test@runningday ~$echo '$PATH'
$PATH
// $PATH维持字面意思，并没有被解析为变量引用
  • curl发送POST请求时，-d后的json数据，如果含有字符串，必须使用双引号"包裹，不能使用单引号'，否则会返回错误码。
1
2
3
4
5
6
7
test@runningday ~$curl -H "Content-Type: application/json" -d "{'app_key': 'key1', 'app_secret': 'secret1'}" https:/open.c.163.com/api/v1/token
{"message":"Unprocessable entity.","code":4220001}
// 其中的payload json数据，全都是用单引号包裹，被报错422

test@runningday ~$curl -H "Content-Type: application/json" -d '{"app_key": "key1", "app_secret": "secret1"}' https:/open.c.163.com/api/v1/token
{"token":"token1","expires_in":"86399"}
// json数据换成用双引号包裹，请求成功
  • 于是乎，如果将上文中json数据的key1，secret1使用变量引用的方式，我们就要注意到上文的2个问题，小心谨慎的拼装出最后的命令。
    • 需要保证json数据都由双引号包裹
    • 需要保证$能够被正确解析为变量引用，所以-d的数据整体也要用双引号包裹，而内部需要使用\来进行转义
1
2
3
4
5
6
test@runningday ~$api_prefix="https://open.c.163.com"
test@runningday ~$k1=key1
test@runningday ~$s1=secret1
test@runningday ~$api=${api_prefix}/api/v1/token
test@runningday ~$curl -H "Content-Type: application/json" -d "{\"app_key\": \"${k1}\", \"app_secret\": \"${s1}\"}" ${api}
{"token":"token1","expires_in":"86399"}

发表于 | 更新于 | 分类于

安装shadowsocks

1
pip install shadowsocks

添加shadowsocks配置文件

1
2
3
4
5
6
7
8
9
10
11
vim /home/test/ss-config.json

{
	"server": "1.1.1.1",
	"server_port": 1010,
	"local_address": "0.0.0.0",
	"local_port": 1080,
	"password": "password",
	"timeout": 600,
	"method": "aes-256-cfb"
}

启动shadowsocks服务

1
2
3
sslocal -c /home/test/ss-config.json //前端运行

nohup sslocal -c /home/test/ss-config.json > /dev/null 2>&1 & //后台运行

开启全局代理

1
export all_proxy=socks5://127.0.0.1:1080

发表于 | 更新于 | 分类于

kubeadm尚处于alpha阶段，安装中会卡住，目前尚未解决

安装kubeadm

前提条件

  • 一台或多台运行Ubuntu 16.04+，CentOS 7或者HypriotOS v1.0.1+系统的机器。

  • 每台机器拥有1GB及以上容量的内存（否则的话，留给你的应用空间就会很少了）

  • 集群中的所有机器都能完全相连（公网互联还是私网互联都行）

    阅读全文 »

发表于 | 更新于 | 分类于

以下流程在minikube中完全跑通

完成效果

  • 可以在kubernetes集群中，搭建自己的docker registry
  • registry支持TLS验证，并且TLS证书支持IP验证【默认只支持域名验证】
  • registry不仅可以被集群中pod访问，而且可以被集群外部访问。
  • registry使用的存储基于NFS，这就意味着你可以将镜像存在网络中其它主机上。

完整流程

创建PV

仓库的首要任务就是存储数据。我们需要决定将数据存储在哪里，可以使用Kubernetes的PersistentVolume对象实现持久化。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# kube-registry-pv.yaml
kind: PersistentVolume
apiVersion: v1
metadata:
        name: kube-system-kube-registry-pv
        labels:
                kubernetes.io/cluster-service: "true"
spec:
        capacity:
                storage: 23Gi
        accessModes:
                - ReadWriteOnce
        storageClassName: nfs-registry
        nfs:
                path: "/home/mine/nfs"
                server: 192.168.1.100

这里面使用nfs作为持久化挂载，关于如何搭建NFS服务器，可以查看我的这篇文章：Linux NFS使用 。

创建PVC来绑定PV

PV持久卷创建完毕后，我们可以使用PersistentVolumeClaim来绑定这个PV。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# kube-registry-pvc.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
        name: kube-registry-pvc
        namespace: kube-system
        labels:
                kubernetes.io/cluster-service: "true"
spec:
        accessModes:
                - ReadWriteOnce
        storageClassName: nfs-registry
        resources:
                requests:
                        storage: 23Gi

创建docker registry

现在我们可以创建一个Docker仓库了。

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
# kube-registry-rc.yaml

apiVersion: v1
kind: ReplicationController
metadata:
    name: kube-registry-v0
    namespace: kube-system
    labels:
        k8s-app: kube-registry
        version: v0
        #kubernetes.io/cluster-service: "true"
spec:
    replicas: 1
    selector:
        k8s-app: kube-registry
        version: v0
    template:
        metadata:
            labels:
                k8s-app: kube-registry
                version: v0
                #kubernetes.io/cluster-service: "true"
        spec:
            containers:
            - name: registry
              image: registry:2
              resources:
                limits:
                    cpu: 100m
                    memory: 100Mi
              env:
              - name: REGISTRY_HTTP_ADDR
                value: :5000
              - name: REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY
                value: /var/lib/registry
              - name: REGISTRY_HTTP_TLS_CERTIFICATE
                value: /certs/server.crt
              - name: REGISTRY_HTTP_TLS_KEY
                value: /certs/server.key
              volumeMounts:
              - name: image-store
                mountPath: /var/lib/registry
              - name: cert-dir
                mountPath: /certs
              ports:
              - containerPort: 5000
                hostPort: 5000
                name: registry
                protocol: TCP
            volumes:
            - name: image-store
              persistentVolumeClaim:
                claimName: kube-registry-pvc
            - name: cert-dir
              secret:
                secretName: registry-tls-secret

这里面使用了hostPort: 5000将Pod中的仓库端口映射到minikube的5000端口中，以便集群外部也能访问这个docker registry。

并且，我们通过使用名叫registry-tls-secret的Secret资源，为这个registry pod提供了TLS必要的server.crt和server.key。这个Secrets以及证书相关，会在下文介绍。

创建Service暴露Pod服务

我们可以将registry Pod作为一个Service暴露出来。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# kube-registry-svc.yaml
apiVersion: v1
kind: Service
metadata:
    name: kube-registry
    namespace: kube-system
    labels:
        k8s-app: kube-registry
        #kubernetes.io/cluster-service: "true"
        kubernetes.io/name: "KubeRegistry"
spec:
    selector:
        k8s-app: kube-registry
    #type: NodePort
    ports:
    - name: registry
      port: 5000
      #nodePort: 30001
      protocol: TCP

OK，目前为止，我们已经建立了docker registry的相关资源，接下来就是准备TLS支持的相关工作。

生成服务端crt证书和key私钥

这一段走的时候不太顺利，尝试了很多方法，也解决了很多问题，大致包括：

  • TLS证书需要支持IP验证。默认情况下证书只支持域名校验，否则会报IP SANs错误cannot validate certificate for 192.168.1.100 because it doesn't contain any IP SANs。
  • 不能使用自签名证书。首先必须要自己生成一个CA crt证书，然后用这个CA来签名服务端证书，然后把该CA证书放在docker的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
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
[ req ]
#default_bits           = 2048
#default_md             = sha256
#default_keyfile        = privkey.pem
distinguished_name      = req_distinguished_name
attributes              = req_attributes
req_extensions          = v3_req

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
countryName_min                 = 2
countryName_max                 = 2
stateOrProvinceName             = State or Province Name (full name)
localityName                    = Locality Name (eg, city)
0.organizationName              = Organization Name (eg, company)
organizationalUnitName          = Organizational Unit Name (eg, section)
commonName                      = Common Name (eg, fully qualified host name)
commonName_max                  = 64
emailAddress                    = Email Address
emailAddress_max                = 64

[ req_attributes ]
challengePassword               = A challenge password
challengePassword_min           = 4
challengePassword_max           = 20

[ v3_req ]
subjectAltName = IP:192.168.99.100

主要是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打包到Secrets中

准备好了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
2
3
4
5
6
7
8
9
10
11
12
.
├── ca.crt
├── ca.key
├── ca.srl
├── kube-registry-pvc.yaml
├── kube-registry-pv.yaml
├── kube-registry-rc.yaml
├── kube-registry-svc.yaml
├── openssl.cnf
├── server.crt
├── server.csr
└── server.key

创建文件start.sh，这样便于随时自动化启动运行：

1
2
3
4
5
kubectl --namespace=kube-system create secret generic registry-tls-secret --from-file=server.crt=./server.crt --from-file=server.key=./server.key
kubectl create -f kube-registry-pv.yaml
kubectl create -f kube-registry-pvc.yaml
kubectl create -f kube-registry-rc.yaml
kubectl create -f kube-registry-svc.yaml

创建文件delete.sh，便于自动化关闭服务：

1
2
3
4
5
kubectl --namespace=kube-system delete secrets registry-tls-secret
kubectl delete -f kube-registry-pv.yaml
kubectl delete -f kube-registry-pvc.yaml
kubectl delete -f kube-registry-rc.yaml
kubectl delete -f kube-registry-svc.yaml

将一切运行起来：

1
2
3
4
5
sh ./delete.sh /*删除所有相关资源以初始化*/
sh ./start.sh /*运行支持tls的docker registry*/
kubectl --namespace=kube-system get all /*查看所有相关资源是否都正常running*/

/*有可能会因为在墙内，导致相关container镜像下载失败，进而不能正常运行，需要自行翻墙*/

验证这一切跑通

我们可以在能访问192.168.99.100的任一台机器上验证这一切，在验证之前，还有一项准备工作要做，否则docker会提示你证书无效：x509: certificate signed by unknown authority

向验证机器的docker提供CA证书：

1
2
3
4
5
sudo mkdir -p /etc/docker/certs.d/192.168.99.100:5000
/*如果之前使用域名作为CN，那这里就用域名作为最后一个目录名字*/

/*将之前生成的ca.crt放在docker custom root ca目录下*/
cp ./ca.crt /etc/docker/certs.d/192.168.99.100:5000/

验证

1
2
3
4
docker pull busybox
docker tag busybox 192.168.99.100:5000/busybox
docker push 192.168.99.100:5000/busybox
docker pull 192.168.99.100:5000/busybox

参考文章

发表于 | 更新于 | 分类于

以下过程在Ubuntu 16.04裸机上完全跑通

本文展示了在Ubuntu 16.04系统上搭建Kubernetes集群的方法，用到了Canonical Kubernetes的发行版本，这是一种快捷搭建本地Kubernetes集群的方法，并能够支持动态增删node节点。

主要搭建步骤是，使用conjure-up工具，结合juju，基于LXD搭建Kubernetes集群，并使用kubelet和kube-proxy将其他机器作为node节点，注册入该集群中。

以下为详细步骤（最好已经翻墙）

阅读全文 »