Kubernetes 是一个跨主机集群的 开源的容器调度平台,它能够自动化应用容器的部署、扩展和操做 , 提供以容器为中心的基础架构。(官方文档第一行)node
每一个微服务都是独立的进程,经过定义好的接口(restful api ,amqp)互相调用mysql
- 不一样服务依赖库致使的混乱,须要将每一个服务独立开(经过docker改善)
![]()
- 服务注册,服务发现:须要动态的更新当前服务。
- 服务编排(即docker容器的编排,docker自身很难解决集群部署的问题):哪些服务须要在哪些宿主机上启动
- Docker Swarm
- Mesos + marathon
- Kubernetes
- master 能够简单的理解为控制中心
- etcd:分布式k-v数据库,根据配置选择是cp仍是ap, k8s只有api server 和etcd通信, 其余组件均和api server 通信
- api server:能够理解为etcd的前置过滤器,换一个视角,它和etcd相似于mysql和文件系统。
- controller manager: 核心,负责将如今的状态调整为etcd上应该的状态,包含了全部的实现逻辑
- scheduler: 简单点说就是给一个pod找一个node。
- slave 能够简单的理解为worker
- kubelet: 负责和master链接,注册node, listen-watch 本node的任务等
- kube-proxy: 用于k8s service对象,以后介绍。
- 容器运行时: 除了docker k8s还支持 rkt等容器实现
- add-on 一些k8s不提供的功能,须要插件实现
- DNS(服务注册发现)
- CNI(容器网络接口实现, ex:fannel)
k8s集群的运行时的大体结构 redis
multiple containers run together说的就是podsql
- pods是k8s管理的最小对象,是一组共享uts, network, ipc namespace的容器(也支持共享pid,默认不开启)
- 每一个pod 会有一个 infrastructure 容器,volumne, network其实都是共用的这个容器的network和volumne
- pod使逻辑上紧密相关的进程适当的隔离,保持必定的相关:
- 一些进程必须在相同而主机上运行
- 扩容须要保持一致
- 等等
实例配置文件docker
[lukou@khand ~]$ kubectl get po redis-master-jvxld -o yaml
apiVersion: v1
kind: Pod
metadata:
annotations:
kubernetes.io/created-by: | {"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicationController","namespace":"default","name":"redis-master","uid":"61a3a1c6-43a9-11e9-9f58-00163f007932","apiVersion":"v1","resourceVersion":"510225"}} creationTimestamp: 2019-03-11T02:57:17Z
generateName: redis-master-
labels:
name: redis-master
name: redis-master-jvxld
namespace: default
ownerReferences:
- apiVersion: v1
controller: true
kind: ReplicationController
name: redis-master
uid: 61a3a1c6-43a9-11e9-9f58-00163f007932
resourceVersion: "510247"
selfLink: /api/v1/namespaces/default/pods/redis-master-jvxld
uid: 61a49472-43a9-11e9-9f58-00163f007932
spec:
containers:
- image: kubeguide/redis-master
imagePullPolicy: Always
name: master
ports:
- containerPort: 6379
protocol: TCP
resources: {}
terminationMessagePath: /dev/termination-log
volumeMounts:
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: default-token-m6g3l
readOnly: true
livenessProbe:
httpGet:
path: /
port: 8080
dnsPolicy: ClusterFirst
nodeName: 127.0.0.1
restartPolicy: Always
securityContext: {}
serviceAccount: default
serviceAccountName: default
terminationGracePeriodSeconds: 30
volumes:
- name: default-token-m6g3l
secret:
defaultMode: 420
secretName: default-token-m6g3l
复制代码
- 确保pod健康
- 肯定并动态调整pod 在集群中中运行的数量,并在pod失败后从新调度新的pod启动
- 相似crontab,进行一些定时任务
![]()
除了rc, rs以外,还有deamonSet, job, cronjob等controller数据库
实例配置文件api
apiVersion: v1
kind: ReplicationController
metadata:
name: kubia
spec:
replicas: 3
selector:
app: kubia
template:
metadata:
labels:
app: kubia
spec:
containers:
- name: kubia
image: luksa/kubia
ports:
- containerPort: 8080
复制代码
rc管理pods,可是pods并非经过rc启动的, rc将pods的配置文件同步给api server, Scheduler分配node, Kubelet跑node.bash
- pod是非持久的,会不断的重启,致使pod的ip是随时变化的,同时pod的数量会是动态变化的,客户端很难和pod直接通信,service是用来解决这一问题的
- service 为提供同一服务的pods 提供了统一的入口
- service 的生命周期内其绑定ip是不会变化的
实例配置文件restful
apiVersion: v1
kind: Service
metadata:
name: redis-master
labels:
name: redis-master
spec:
ports:
- port: 6379
targetPort: 6379
selector:
name: redis-master
复制代码
[lukou@khand ~]$ kubectl get svc
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes 10.254.0.1 <none> 443/TCP 26d
redis-master 10.254.61.141 <none> 6379/TCP 21d
复制代码
经过环境变量或者DNS 能够查询service 的ip和端口网络
- 新建的pod会将全部的已经建立service的 ip和port存入环境变量
[lukou@khand ~]$ kubectl get pods
NAME READY STATUS RESTARTS AGE
redis-master-jvxld 1/1 Running 0 21d
[lukou@khand ~]$ kubectl exec redis-master-jvxld env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=redis-master-jvxld
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT=tcp://10.254.0.1:443
KUBERNETES_PORT_443_TCP=tcp://10.254.0.1:443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_ADDR=10.254.0.1
KUBERNETES_SERVICE_HOST=10.254.0.1
KUBERNETES_SERVICE_PORT=443
HOME=/root
[lukou@khand ~]$ kubectl delete po --all
pod "redis-master-jvxld" deleted
[lukou@khand ~]$ kubectl get pods
NAME READY STATUS RESTARTS AGE
redis-master-b7mkh 0/1 ContainerCreating 0 6s
[lukou@khand ~]$ ^C
[lukou@khand ~]$ kubectl get pods
NAME READY STATUS RESTARTS AGE
redis-master-b7mkh 1/1 Running 0 1m
[lukou@khand ~]$ kubectl exec redis-master-b7mkh env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=redis-master-b7mkh
KUBERNETES_PORT=tcp://10.254.0.1:443
KUBERNETES_PORT_443_TCP=tcp://10.254.0.1:443
KUBERNETES_PORT_443_TCP_ADDR=10.254.0.1
REDIS_MASTER_SERVICE_PORT=6379
KUBERNETES_SERVICE_PORT=443
REDIS_MASTER_PORT_6379_TCP_PORT=6379
KUBERNETES_SERVICE_HOST=10.254.0.1
REDIS_MASTER_SERVICE_HOST=10.254.61.141
REDIS_MASTER_PORT=tcp://10.254.61.141:6379
REDIS_MASTER_PORT_6379_TCP=tcp://10.254.61.141:6379
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT_443_TCP_PORT=443
REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
REDIS_MASTER_PORT_6379_TCP_ADDR=10.254.61.141
HOME=/root
复制代码
- 经过dns服务,注册cluster域名,相似
redis-master.default
以前建立的service只有一个集群内的固定ip
[lukou@khand ~]$ kubectl get svc
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes 10.254.0.1 <none> 443/TCP 26d
redis-master 10.254.61.141 <none> 6379/TCP 21d
复制代码
若是须要在集群外访问有三种方法
- 默认的service 的类型是 'ClusterIP',修改成NodePort便可
apiVersion: v1
kind: Service
metadata:
name: redis-master
labels:
name: redis-master
spec:
type: NodePort
ports:
- port: 6379
targetPort: 6379
nodePort: 30123 // The range of valid ports is 30000-32767
selector:
name: redis-master
复制代码
[lukou@khand ~]$ kubectl get svc
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes 10.254.0.1 <none> 443/TCP 26d
redis-master 10.254.61.141 <nodes> 6379:30123/TCP 21d
复制代码
- 建立一个loadbalance
![]()
- 建立Ingress resource
![]()
- 简单地说deployment是rc的上一层,用来管理rc的
- 主要功能是管理pod运行的版本
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: kubia
spec:
replicas: 3
template:
metadata:
name: kubia
labels:
app: kubia
spec:
containers:
- image: luksa/kubia:v1
name: nodejs
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate
复制代码
升级的cmd kubectl set image deployment kubia nodejs=luksa/kubia:v2
大体实现的逻辑是,deployment不断的下降旧版本rc的 replicas, 增长新版本的replicas
![]()
就像rc并非直接控制pod同样,deployment也是相似,deployment声明式的通知api server 须要升级后的结果,具体升级的逻辑由development controller去处理
![]()