一个service的4个特征:
拥有唯一指定的名字
拥有一个endpoint(虚拟cluster ip +service port)
拥有提供远程服务能力
能被映射到提供服务能力的一组容器上
一个pod =一个pause天使容器+many 业务容器
pause:每一个pod的共享网络栈和volume挂载卷
启示：密切相关的服务应该放在同一个pod
对比传统it的服务扩容与服务升级，k8s的优势
服务升级：修改replicas
服务扩容：修改resource
dokcer 启动时候的配置说明：
cd /etc/sysconfig/docker
修改options中的内容
--insecure-registry gcr.io :docker去谷歌的仓库拉天使image,pause_adm64
--selinux-enabd=flase：关闭selinux,
关闭原因：恩～，１，nsa主导开发，２，懒得搞
k8s启动说明：
systemctl start etcd
systemctl start docker
systemctl start kube-apiserver
systemctl start kubde-controller-manager
systemctl start kube-scheduler
systemctl start kubelet
systemctl start kube-proxy
说明：
master:kube-apiserver，kubde-controller-manager，kube-scheduler，etcd
slave: kubelet,kube-proxy, docker
question：why comapany all on one?is it passroble not on one?
遗留问题：
etcd 持久化
service name与endpoint的匹配，服务发现机制。
业务pod与天使pod共享volume与网络。
遗留
k8s平滑的升级：
假设有５个pod,我们升级的过程中，我们升级总是保持在5个，
１个pod died,同时一个pod born,
这种的升级方式叫做rolling update.
kubectl scale rc mysql --replicas=3
脚本控制升级备份等于3
replica set:升级的rc机制，支持基于集合的label selector
spec:
selector:
matchLables:
tier: frontend
matchExpressions:
- {key: tier,oprator: In, values: [frontend]}\
在未来的k8s版本中，replicas set 与 deployment 会逐渐取代rc的作用
deployment的定义与replica set相似，也支持基于集合的label selector。
deployment可以看成是rc 的升级，可以实时的知道当前pod的部署进度
deployment是基于replica set的。所以查看deployment状态有
kubectl get rs
HPA:pod自动化扩容升级
跟踪rc控制的所有的pod的负载情况，确定是否需要调整pod的副本数
判断标准：cpuutilizationpercentage,程序自定义的度量目标（tps,qps）
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
namespace: default
spec:
scaleTargetRef:
apiVersion: v1
kind: ReplicationController
name: php-apache
minReplicas: 1
maxReplicas: 10
targetCPUUtilizationPercentage: 50
监控php-apache的rc,最小是１，最大是10,
CPUUtilizationPercentage超过50/100会触发动态调整。
svcname与cluster ip的关联：
最早的版本的k8s是使用环境变量：docker inspect containerid 可以看到
ＤＮＳ域名映射
k8s在单机的pod是可以通过k8s服务发现机制互相访问
k8s在多机的的pod是不提供网络设置的，
需要借助一些跨主机的容器网络设置工具
fannel,open vswitch,weave,calico实现跨主机的容器网络互通
配置与服务进行分离
configmap:定义配置的service
服务pod:提取configmap中的配置使用
configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config
namespace: default
data:
special.how: very
special.type: charm
pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox
command: [ "/bin/sh", "-c", "env" ]
env:
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: special.how
k8s的pod重启策略
always:当容器失效的时候，由k8s自动重新启动该容器
onfailure:容器种植运行，并且退出码不为０，重启
never:不论容器的运行状态怎么样，都不会重启启动该容器
pod扩容与升级
扩容：
replicas
HPA:需要安装heapster组件
创建php-apache实例的RC
通过kubectl create -f php-rc.yaml文件创建RC.
文件内容如下：
RC
apiVersion: v1
kind: ReplicationController
metadata:
name: php-apache
spec:
replicas: 1
template:
metadata:
name: php-apache
labels:
app: php-apache
spec:
containers:
- name: php-apache
image: gcr.io/google_containers/hpa-example:latest
imagePullPolicy: IfNotPresent
resources:
requests:
cpu: 200m
ports:
- containerPort: 80
创建php-apache实例的SVC
通过kubectl create -f php-svc.yaml文件创建SVC.文件内容如下：
apiVersion: v1
kind: Service
metadata:
name: php-apache
labels:
k8s-app: php-apache
spec:
ports:
# The port that this service should serve on.
- port: 80
# Label keys and values that must match in order to receive traffic for this service.
selector:
app: php-apache
创建HPA
通过kubectl create -f hpa-example.yaml文件创建HPA.文件内容如下：
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
namespace: default
spec:
scaleTargetRef:
apiVersion: v1
kind: ReplicationController
name: php-apache
minReplicas: 1
maxReplicas: 10
targetCPUUtilizationPercentage: 50
滚动升级：matrix封装了k8s的滚动升级，这里记一下原生态的k8s升级
step1:配置升级的rc文件，name,version,image都得修改为新的version
step2:kubectl rolling-update podname -f rc.yaml
k8s会先去新建pod，然后杀死旧的pod.完成集群更新的工作
可以看一看的文章
https://blog.csdn.net/ximenghappy/article/details/70242322
网友评论