Docker/Kubernetes – Page 3

Kubernetes内部监控集成: Grafana+Heapster+Influxdb

2017-08-20 17:28:00September 21, 2019 Swire

2018-06-03 Update: 在官方发布1.10.0 版本的ChangeLog中,–cadvisor-port被标记为Deprecation,其将于 1.12 版本中被默认置为关闭(可手动开启), 并在 1.13 版本中被移除. 简介容器的出现使得应用服务变得更加扁平易扩展,从而导致监控对象的碎片化,使得监控实现更加困难. 得益于 Kubernetes / Swarm / Rancher / Mesos 等编排技术的出现,让开发人员有了相对统一的手段去监控这些运行在容器的服务,并收集数据. 而 Kubernetes 通过建立抽象层，比如 pods 和 services, 简化了容器的管理,让我们无需关心容器运行过程和它的资源消耗.但为了确保集群更安全,应用服务更高性能,因此我们需要监控我们的应用,容器,以及 Kubernetes 本身. 当下对于容器监控的主流方法是用来自的谷歌的 cAdvisor 搜集数据. cAdvisor是一个用Go编写的服务,它会收集当前节点以及运行容器的监控数据: cpu, memory, … “Kubernetes内部监控集成: Grafana+Heapster+Influxdb”

kubectl get csr 显示No Resources Found的解决记录

2017-08-17 17:45:00September 12, 2019 Swire

在添加了CA证书并部署了kube-apiserver,kube-controller-manager以及kube-scheduler几个k8s的master组件后,添加kubelet组件,同时生成证书认证的配置文件. kubelet 启动时向 kube-apiserver 发送 TLS bootstrapping 请求，需要先将 bootstrap token 文件中的 kubelet-bootstrap 用户赋予 system:node-bootstrapper 角色，然后 kubelet 才有权限创建认证请求(certificatesigning requests)。文件token.csv内容: e21b2365eb6e3c86a670dec0bdb511cc,kubelet-bootstrap,10001,”system:kubelet-bootstrap” #正常情况下只需创建一次认证即可.配置根据token.csv中的内容自行修改. kubectl create clusterrolebinding kubelet-bootstrap –clusterrole=system:node-bootstrapper –user=kubelet-bootstrap 得到kubelet kubeconfig文件后,使用命令kubectl get csr可以看到还未认证的节点. 使用命令kubectl certificate approve {NodeName}可以加入TLS认证. … “kubectl get csr 显示No Resources Found的解决记录”

kube-apiserver搭配etcd2显示rpc error: code = 13 desc = transport is closing解决记录

2017-08-14 20:03:43September 12, 2019 Swire

code=13 按照官方的定义，应该是INTERNAL，即来自内部的错误，但有时也是自己配置上的错误. 在Ubuntu 16.04上安装kubernetes，etcd是直接apt-get安装的,当前版本为2.2.5，而kubernetes在1.5版本后默认使用etcd3的配置项。因此在创建kube-apiserver.service配置文件时，需要指定etcd版本只需加入–storage-backend=etcd2参数即可. Ubuntu16.04的kube-apiserver.service配置文件示例,其中192.168.1.220替换为本机IP: [Unit] Description=Kubernetes API Server Documentation=https://github.com/GoogleCloudPlatform/kubernetes After=network.target [Service] User=root ExecStart=/usr/bin/kube-apiserver \ –admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota \ –advertise-address=192.168.1.220 \ –allow-privileged=true \ –apiserver-count=1 \ –audit-log-maxage=30 \ –audit-log-maxbackup=1 \ –audit-log-maxsize=100 \ –audit-log-path=/var/lib/audit.log \ –authorization-mode=RBAC \ –bind-address=192.168.1.220 … “kube-apiserver搭配etcd2显示rpc error: code = 13 desc = transport is closing解决记录”

etcd cluster-health响应client: etcd cluster is unavailable or misconfigured解决记录

2017-08-14 16:59:23September 12, 2019 Swire

大体分两种情况: 1.防火墙或者iptables的原因. 2.etcd 配置错误. 解决措施第一种情况比较好解决:开放对应端口/应用白名单,或者直接关闭防火墙第二种就需要参考官方指导，搞明白每个设置项的功能. 放个Ubuntu16.04的示例,CentOS的改一下依赖的network名称就可以,192.168.1.220替换为本机IP: [Unit] Description=etcd – highly-available key value store Documentation=https://github.com/coreos/etcd Documentation=man:etcd After=network.target Wants=network-online.target [Service] #Environment=DAEMON_ARGS= #Environment=ETCD_NAME=%H #Environment=ETCD_DATA_DIR=/var/lib/etcd/default #EnvironmentFile=-/etc/default/%p Type=notify User=etcd WorkingDirectory=/var/lib/etcd/ PermissionsStartOnly=true #ExecStart=/bin/sh -c “GOMAXPROCS=(nproc) /usr/bin/etcdDAEMON_ARGS” #ExecStart=/usr/bin/etcd $DAEMON_ARGS ExecStart=/usr/bin/etcd … “etcd cluster-health响应client: etcd cluster is unavailable or misconfigured解决记录”

运行SourceTree后GitLab响应Forbidden解决方法

2017-08-11 15:06:51October 27, 2021 Swire

公司的Git服务是由GitLab的docker容器搭建的，当初我搭建/升级/启动都很方便，且没修改gitlab.rb配置文件，用的都是默认配置. 在SourceTree升级到2.1.10.0后，竟然坑爹的默认后台并发查询git仓库更新，近百个项目，这个并发查询超了GitLab并发访问的阈值，直接封了IP. 解决方法根据官方说明:Rack Attack和IP Whitelist，解决方法三种: 添加IP白名单. 加大并发阈值. 直接关闭Rack Attack. 这里我是加大并发阈值和添加IP白名单. 因为跑的是容器,那么就直接进挂载的文件夹里找到config/gitlab.rb后，打开并找到gitlab_rails[‘rack_attack_git_basic_auth’]项，去掉注释,并修改为: gitlab_rails[‘rack_attack_git_basic_auth’] = { ‘enabled’ => true, ‘ip_whitelist’ => [“127.0.0.1″,”192.168.xxx.xxx”], ‘maxretry’ => 200, ‘findtime’ => 60, ‘bantime’ => 3600 } 这里在ip_whitelist字段后添加白名单IP即可，然后增加maxretry字段的值。

Debian7通过apt-get升级内核到3.16安装Docker

2017-05-16 10:52:01September 03, 2019 Swire

目前docker-ce 17.03版本，官方要求Debian版本大于wheezy 7.7或者Linux Kernel版本大于3.10，因此需要升级默认Debian 7的3.2.0内核版本。官方说明添加官方backports源: vi /etc/apt/sources.list deb http://ftp.debian.org/debian/ wheezy-backports main # 或者用下方阿里的源也可以 # deb http://mirrors.aliyun.com/debian-backports/ wheezy-backports main contrib non-free # deb-src http://mirrors.aliyun.com/debian-backports/ wheezy-backports main contrib non-free 然后获取最新包版本： apt-get update && apt-get -t wheezy-backports … “Debian7通过apt-get升级内核到3.16安装Docker”

创建基于Fannel网络的Kubernetes 1.5.4

2017-03-20 19:12:23September 12, 2019 Swire

Kubernetes 是个基于容器的调度编排工具,源于谷歌,现在全球的开发者在为其贡献代码.它极大的方便了分布式部署服务的难点,我认为这应该是将来服务发布部署主流的方向. Kubernetes现在底层调度的是Docker.去年我接触了Docker,Docker的容器给我的感受就是它确实是比 KVM 模式便捷许多,并且 KVM 有的资源分配与环境隔离Docker都已经实现的较为完全了,相比于 KVM,其优势就是任务的快速创建和资源的快速回收.Kubernetes则是在此之上统一管理调度这些任务和资源. 而Kubernetes的难点在于其部署的过程极为复杂,并且网络配置也较为困难.我看了一天,也才略微懂了皮毛. 参考Kubernetes.io 准备环境需要准备好各个节点的名称,IP,以及需要的docker,etcd,kubernetes等运行程序,全部流程使用root权限,关闭SELinux与Firewalld服务. 节点名称和IP 三个节点,既为master也为node,运行系统为 CentOS 7. Node Name IP node1 192.168.200.21 node2 192.168.200.22 node3 192.168.200.23 将每个节点的Hostname改为对应的Node Name: # node-1 hostnamectl –static set-hostname node1 # node-2 … “创建基于Fannel网络的Kubernetes 1.5.4”

Docker容器中与主机上文件的相互复制

2016-07-28 15:26:05August 28, 2019 Swire

搞笑的是,我之前从容器中把文件复制到宿主机上时,一直都是直接到/var/lib/docker/containers/中直接寻找的.我尼玛,这要是只有一两个在跑的容器那找到对应目录还是比较简单的,但要是跑上数十个容器岂不得找到疯. 知道今天才知道原来存在docker cp命令,之前难道是我眼瞎???? 居然一直都没看到docker help下的帮助提示. 命令格式为: docker cp [container id /container name]:/path /hostpath docker cp /hostpath [container id /container name]:/path