‘壹’ k8s为什么需要软路由
使用RouterOS, 搭建虚拟路由器，并且配置多个网关互通。配置步骤如下。
基础配置
1. RouterOS 服务器，设置如下
‘贰’ 如何配置kubernetes dns
创建一个简单的 Pod 来用作测试环境
使用以下内容创建一个名为 busybox.yaml 的文件：
busybox.yaml
apiVersion: v1
kind: Pod
metadata:
name: busybox
namespace: default
spec:
containers:
- name: busybox
image: busybox
command:
- sleep
- "3600"
imagePullPolicy: IfNotPresent
restartPolicy: Always
然后使用此文件创建一个 pod 并验证其状态：
$ kubectl create -f busybox.yaml
pod "busybox" created
$ kubectl get pods busybox
NAME READY STATUS RESTARTS AGE
busybox 1/1 Running 0 <some-time>
一旦该 pod 运行，您就可以在环境中执行 nslookup。如果您看到如下所示的内容，则 DNS 工作正常。
$ kubectl exec -ti busybox -- nslookup kubernetes.default
Server: 10.0.0.10
Address 1: 10.0.0.10
Name: kubernetes.default
Address 1: 10.0.0.1
如果 nslookup 命令失败，请检查以下内容：
首先检查本地 DNS 配置
看一看 resolv.conf 文件。（有关更多信息，请参阅从节点继承 DNS和 下面的已知问题）
$ kubectl exec busybox cat /etc/resolv.conf
验证搜索路径和名称服务器是否设置如下（请注意，搜索路径可能因不同的云提供商而异）：
search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal
nameserver 10.0.0.10
options ndots:5
以下错误表明 kube-dns 附加组件或相关服务存在问题：
$ kubectl exec -ti busybox -- nslookup kubernetes.default
Server: 10.0.0.10
Address 1: 10.0.0.10
nslookup: can't resolve 'kubernetes.default'
或者
$ kubectl exec -ti busybox -- nslookup kubernetes.default
Server: 10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
nslookup: can't resolve 'kubernetes.default'
检查 DNS pod 是否正在运行中
使用 kubectl get pods 命令验证 DNS pod 是否正在运行中。
$ kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
NAME READY STATUS RESTARTS AGE
...
kube-dns-v19-ezo1y 3/3 Running 0 1h
如果您看到没有 pod 正在运行中，或者 pod 已失败/已完成，那么在当前环境中，默认情况下可能不会部署 DNS 插件，您将不得不手动部署它。
检查 DNS pod 中的错误
使用 kubectl logs 命令查看 DNS 守护程序的日志。
$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c kubedns
$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c dnsmasq
$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c sidecar
看看有没有可疑的日志。字母 ‘W‘、’E‘、’F’ 表示警告、错误和失败。请搜索具有这些日志级别的条目，并使用kubernetes 问题来报告意外错误。
DNS服务起来了吗？
通过使用 kubectl get service 命令验证 DNS 服务已启动。
$ kubectl get svc --namespace=kube-system
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
...
kube-dns 10.0.0.10 <none> 53/UDP,53/TCP 1h
...
如果您已经创建了该服务，或者应该在默认情况下创建它，但它没有出现，请参阅调试服务以获取更多信息。
DNS endpoints 是否暴露？
您可以使用 kubectl get endpoints 命令验证是否暴露了了 DNS endpoints。
$ kubectl get ep kube-dns --namespace=kube-system
NAME ENDPOINTS AGE
kube-dns 10.180.3.17:53,10.180.3.17:53 1h
如果您没有看到 endpoints，请参阅调试服务文档中的 endpoints 部分 。
有关其他 Kubernetes DNS 示例，请参阅 Kubernetes GitHub 仓库中的cluster-dns 示例。
已知问题
Kubernetes 安装不会将节点的 resolv.conf 文件配置为默认使用集群 DNS，因为该过程本身就是发行版的。最终可能会这么实现。
Linux 的 libc 不可能摆脱（见 2005 年的这个 bug）只有 3 个 DNSnameserver记录和 6 个 DNSsearch记录的限制。Kubernetes 需要消耗 1 个nameserver记录和 3 条search记录。这意味着如果本地安装已经使用了 3 个nameserver或使用了多于 3 条search，那么其中一些设置将会丢失。作为部分解决方法，节点可以运行dnsmasq，它将提供更多nameserver条目，但没有更多的search条目。您也可以使用 kubelet--resolv-conf标志。
如果您使用 Alpine 3.3 或更低版本作为您的基本镜像，由于 Alpine 的某些已知问题，DNS 可能无法正常工作。
kubernetes 调试 DNS 解析
‘叁’ k8s部署fabric,用minikube部署的k8s集群环境，kube-dns出现了问题
1. 安装kubectl
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl && chmod +x kubectl && sudo mv kubectl /usr/local/bin/
1
下载指定版本，例如下载v1.9.0版本
curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.9.0/bin/linux/amd64/kubectl && chmod +x kubectl && sudo mv kubectl /usr/local/bin/
1
2. 安装minikube
minikube的源码地址：https://github.com/kubernetes/minikube
2.1 安装minikube
以下命令为安装latest版本的minikube。
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/
1
安装指定版本可到https://github.com/kubernetes/minikube/releases下载对应版本。
‘肆’ 如何入门k8s
Kubernetes（简称K8S） 是Google开源的分布式的容器管理平台，方便我们在服务器集群中管理我们容器化应用。
节点（Master node and Worker node）
节点通常指的就是服务器，在k8s中有两种节点：管理节点（Master Node）和工作节点（Worker Node）
管理节点（Master Node）：负责管理整个k8s集群，一般由3个管理节点组成HA的架构。
工作节点（Worker Node）：主要负责运行容器。命名空间(Namespace)
k8s命名空间主要用于隔离集群资源、隔离容器等，为集群提供了一种虚拟隔离的策略；默认存在3个名字空间，分别是默认命名空间 default、系统命名空间 kube-system 和 kube-public。Object
k8s 对象(Object)是一种持久化存储并且用于表示集群状态的实体。k8s 对象其实就是k8s自己的配置协议，总之我们可以通过定义一个object让k8s根据object定义执行一些部署任务、监控任务等等。POD
Pod是 Kubernetes 部署应用或服务的最小的基本单位。一个Pod 封装多个应用容器（也可以只有一个容器）、存储资源、一个独立的网络 IP 以及管理控制容器运行方式的策略选项。副本集(Replica Set，RS)
是一种控制器，负责监控和维护集群中pod的副本(replicas)数，确保pod的副本数是我们期望的样子。部署(Deployment)
表示对k8s集群的一次更新操作，是k8s集群中最常用的Object，主要用于部署应用。支持滚动升级。服务(service)
是对应用的抽象，也是k8s中的基本操作单元，一个服务背后由多个pod支持，服务通过负载均衡策略将请求转发到容器中。Ingress
是一种网关服务，可以将k8s服务通过http协议暴露到外部。无状态应用 & 有状态应用
无状态应用指的是应用在容器中运行时候不会在容器中持久化存储数据，应用容器可以随意创建、销毁；如果一个应用有多个容器实例，对于无状态应用，请求转发给任何一个容器实例都可以正确运行。例如：web应用
有状态应用指的是应用在容器中运行时候需要稳定的持久化存储、稳定的网络标识、固定的pod启动和停止次序。例如：mysql数据库
‘伍’ kubernetes集群怎么访问外部的服务mysql，redis
k8s访问集群外独立的服务最好的方式是采用Endpoint方式(可以看作是将k8s集群之外的服务抽象为内部服务)，以mysql服务为例：
创建mysql-endpoints.yaml
apiVersion: v1
kind: Endpoints
metadata:
name: mysql-test
namespace: default
subsets:
- addresses: - ip: 10.1.0.32 ports:
- port: 3306多个端口的话可以在此处列出123456789101112
创建mysql-service.yaml
apiVersion: v1kind: Servicemetadata:
name: mysql-testspec:
ports:
- port: 3306同样多端口需要列出
‘陆’ 如何进行K8S存储系统
在K8S运行的服务，从简单到复杂可以分成三类：无状态服务、普通有状态服务和有状态集群服务。下面分别来看K8S是如何运行这三类服务的。
无状态服务，K8S使用RC（或更新的Replica Set）来保证一个服务的实例数量，如果说某个Pod实例由于某种原因Crash了，RC会立刻用这个Pod的模版新启一个Pod来替代它，由于是无状态的服务，新启的Pod与原来健康状态下的Pod一模一样。在Pod被重建后它的IP地址可能发生变化，为了对外提供一个稳定的访问接口，K8S引入了Service的概念。一个Service后面可以挂多个Pod，实现服务的高可用。
普通有状态服务，和无状态服务相比，它多了状态保存的需求。Kubernetes提供了以Volume和Persistent Volume为基础的存储系统，可以实现服务的状态保存。
有状态集群服务，与普通有状态服务相比，它多了集群管理的需求。K8S为此开发了一套以Pet Set为核心的全新特性，方便了有状态集群服务在K8S上的部署和管理。具体来说是通过Init Container来做集群的初始化工作，用Headless Service来维持集群成员的稳定关系，用动态存储供给来方便集群扩容，最后用Pet Set来综合管理整个集群。
要运行有状态集群服务要解决的问题有两个,一个是状态保存，另一个是集群管理。我们先来看如何解决第一个问题：状态保存。Kubernetes有一套以Volume插件为基础的存储系统，通过这套存储系统可以实现应用和服务的状态保存。
K8S的存储系统从基础到高级又大致分为三个层次：普通Volume，Persistent Volume和动态存储供应。
1.普通Volume
最简单的普通Volume是单节点Volume。它和Docker的存储卷类似，使用的是Pod所在K8S节点的本地目录。
第二种类型是跨节点存储卷，这种存储卷不和某个具体的K8S节点绑定，而是独立于K8S节点存在的，整个存储集群和K8S集群是两个集群，相互独立。
跨节点的存储卷在Kubernetes上用的比较多，如果已有的存储不能满足要求，还可以开发自己的Volume插件，只需要实现Volume.go里定义的接口。如果你是一个存储厂商，想要自己的存储支持Kubernetes上运行的容器，就可以去开发一个自己的Volume插件。
2.persistent volume
它和普通Volume的区别是什么呢？
普通Volume和使用它的Pod之间是一种静态绑定关系，在定义Pod的文件里，同时定义了它使用的Volume。Volume是Pod的附属品，我们无法单独创建一个Volume，因为它不是一个独立的K8S资源对象。
而Persistent Volume简称PV是一个K8S资源对象，所以我们可以单独创建一个PV。它不和Pod直接发生关系，而是通过Persistent Volume Claim，简称PVC来实现动态绑定。Pod定义里指定的是PVC，然后PVC会根据Pod的要求去自动绑定合适的PV给Pod使用。
‘柒’ 如何在Kubernetes中部署一个高可用的PostgreSQL集群环境
虽然 kubernetes 社区一直在努力使得有状态应用成为一等公民，也推出了 statefulset 控制器支持 pod 的顺序部署，稳定的域名访问和存储访问。但鉴于 MySQL 部署运维的多样性和复杂性，在 kubernetes 上部署 MySQL 仍然要面临众多挑战。
1、业务流量入口的配置方式
传统虚拟机环境下，我们通过虚IP的方式，让业务应用都配置事先定义的一个虚IP为链接数据库的地址，然后由高可用服务保证虚IP始终能被路由到master数据库。在kubernetes中，出现了一层网络插件屏蔽了底层网络拓扑，高可用服务管理虚IP的方式需要随之适应调整，比如通过service结合标签完成虚IP的漂移，但service本身是kubernetes提供的一项功能，其可靠性和性能都取决于kubernetes服务的稳定。以性能来说，service是kubeproxy组件通过配置iptables实现的，当iptables规则较多时不可避免的会产生时延，需要我们针对性的解决。
2、容器隔离带来的监控视野问题
在 kubernetes 中，如果将 MySQL 制作为 container 运行在一个 pod 中，container 会将 MySQL 进程和运行环境隔离在一个单独的 namespace 中。监控组件在获取 MySQL 的一些 metirc 时，可能不得不进入与 MySQL 同一个 namespace 中，在部署和设计监控组件时需要考虑到这些限制。
3、存储在 kubernetes 中，支持配置各种不同的存储。
如果使用本地存储 local persistent volume，则需要绑定 MySQL 在一个固定的节点，这就完全浪费了 kubernetes 灵活调度的天然优势；而如果使用远程共享存储，确实是将 MySQL 进程与其存储完全解耦，使得 MySQL 进程可以在任意节点调度，然而考虑到高 I/O 吞吐量的情况，就不是那么美好了。设计时需要考量远程存储是否能够满足 MySQL 的带宽要求。
4、高可用/备份恢复
kubernetes 提供的 statefulset 控制器只能提供最基本的部署，删除功能，无法实现完善的 MySQL 集群高可用/备份恢复操作。对于有状态应用的部署，仍需要定制开发，所以多数公司提供了定制的 operator 来完成应用容器的管理。比如 etcd operator，MySQL operator，后文将为大家详述我测试使用 MySQL operator 的一些记录。
‘捌’ Linux里面k8s有几种网络模式
1、单机网络模式：Bridge 、Host、Container、None
2、多机网络模式：一类是 Docker 在 1.9 版本中引入Libnetwork项目，对跨节点网络的原生支持；一类是通过插件（plugin）方式引入的第三方实现方案，比如 Flannel，Calico 等等。
‘玖’ 如何访问k8s集群内部署的mysql服务
虽然 kubernetes 社区一直在努力使得有状态应用成为一等公民，也推出了 statefulset 控制器支持 pod 的顺序部署，稳定的域名访问和存储访问。但鉴于 MySQL 部署运维的多样性和复杂性，在 kubernetes 上部署 MySQL 仍然要面临众多挑战。
1、业务流量入口的配置方式
传统虚拟机环境下，我们通过虚IP的方式，让业务应用都配置事先定义的一个虚IP为链接数据库的地址，然后由高可用服务保证虚IP始终能被路由到master数据库。在kubernetes中，出现了一层网络插件屏蔽了底层网络拓扑，高可用服务管理虚IP的方式需要随之适应调整，比如通过service结合标签完成虚IP的漂移，但service本身是kubernetes提供的一项功能，其可靠性和性能都取决于kubernetes服务的稳定。以性能来说，service是kubeproxy组件通过配置iptables实现的，当iptables规则较多时不可避免的会产生时延，需要我们针对性的解决。
2、容器隔离带来的监控视野问题
在 kubernetes 中，如果将 MySQL 制作为 container 运行在一个 pod 中，container 会将 MySQL 进程和运行环境隔离在一个单独的 namespace 中。监控组件在获取 MySQL 的一些 metirc 时，可能不得不进入与 MySQL 同一个 namespace 中，在部署和设计监控组件时需要考虑到这些限制。
3、存储在 kubernetes 中，支持配置各种不同的存储。
如果使用本地存储 local persistent volume，则需要绑定 MySQL 在一个固定的节点，这就完全浪费了 kubernetes 灵活调度的天然优势；而如果使用远程共享存储，确实是将 MySQL 进程与其存储完全解耦，使得 MySQL 进程可以在任意节点调度，然而考虑到高 I/O 吞吐量的情况，就不是那么美好了。设计时需要考量远程存储是否能够满足 MySQL 的带宽要求。
4、高可用/备份恢复
kubernetes 提供的 statefulset 控制器只能提供最基本的部署，删除功能，无法实现完善的 MySQL 集群高可用/备份恢复操作。对于有状态应用的部署，仍需要定制开发，所以多数公司提供了定制的 operator 来完成应用容器的管理。比如 etcd operator，MySQL operator，后文将为大家详述我测试使用 MySQL operator 的一些记录。
‘拾’ 如何在K8S平台部署微服务
使用Rancher来运行Kubernetes有很多优势。大多数情况下能使用户和IT团队部署和管理工作更加方便。Rancher自动在Kubernetes后端实现etcd 的HA，并且将所需要的服务部署到此环境下的任何主机中。在设置访问控制，可以轻易连接到现有的LDAP和AD基础构架。Rancher还可以自动实现容器联网以及为Kubernetes提供负载均衡服务。通过使用Rancher，你将会在几分钟内有拥有Kubernetes的HA实现。
命名空间
现在我们的集群已经运行了，让我们进入并查看一些基本的Kubernetes资源吧。你可以访问Kubernetes集群也可以直接通过kubectl CLI访问，或者通过Rancher UI 访问。Rancher的访问管理图层控制可以访问集群，所以你需要在访问CLI前从Rancher UI那里生成API密匙。
我们来看下第一个Kubernetes资源命名空间，在给定的命名空间中，所有资源名称必须有唯一性。此外,标签是用来连接划定到单个命名空间的资源。这就是为什么同一个Kubernetes集群上可以用命名空间来隔离环境。例如，你想为应用程序创建Alpha, Beta和生产环境，以便可以测试最新的更改且不会影响到真正的用户。最后创建命名空间，复制下面的文本到namespace.yaml文件，并且运行 kubectl -f namespace.yaml 命令，来创建一个beta命名空间。
kind: Namespace
apiVersion: v1
metadata:
name: beta
labels:
name: beta
当然你还可以使用顶部的命名空间菜单栏从Rancher UI上创建、查看和选择命名空间。
你可以使用下面的命令，用kubectl来为CLI交互设置命名空间：
$ kubectl config set-context Kubernetes --namespace=beta.
为了验证目前context是否已经被设置好，你可以使用config view命令，验证一下输出的命名空间是否满足你的期望。
$ kubectl config view | grep namespace command namespace: beta
Pods
现在我们已经定义好了命名空间，接下来开始创建资源。首先我们要看的资源是Pod。一组一个或者多个容器的Kubernetes称为pod，容器在pod 里按组来部署、启动、停止、和复制。在给定的每个主机种类里，只能有一个Pod,所有pod里的容器只能在同一个主机上运行，pods可以共享网络命名空间,通过本地主机域来连接。Pods也是基本的扩展单元,不能跨越主机,因此理想状况是使它们尽可能接近单个工作负载。这将消除pod在扩展或缩小时产生的副作用，以及确保我们创建pods不太耗资源而影响到主机。
我们来给名为mywebservice的pod定义，在规范命名web-1-10中它有一个容器并使用nginx容器镜像，然后把端口为80下的文本添加至pod.yaml文档中。
apiVersion: v1
kind: Pod
metadata:
name: mywebservice
spec:
containers:
- name: web-1-10
image: nginx:1.10
ports:
- containerPort: 80
使用kubetl create命令创建pod，如果您使用set-context command设置了您的命名空间，pods将会在指定命名空间中被创立。在通过运行pods命令去验证pod状态。完成以后，我们可以通过运行kubetl delete命令删除pod。
$ kubectl create -f ./pod.yaml
pod "mywebservice" created
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
mywebservice 1/1 Running 0 37s
$ kubectl delete -f pod.yaml
pod "mywebservice" deleted
在Rancher UI 中查看pod，通过顶端的菜单栏选择 Kubernetes > Pods 。