容器化进阶Kubernetes（K8S）详解-Toy模板网

这篇具有很好参考价值的文章主要介绍了容器化进阶Kubernetes（K8S）详解。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

1.Kubernetes概述

1.1 Kubernetes介绍

1.1.1 Kubernetes是什么及作用

Kubernetes(K8S)是Google在2014年发布的一个开源项目，用于自动化容器化应用程序的部署、扩展和管理。

Kubernetes通常结合docker容器工作，并且整合多个运行着docker容器的主机集群。

官网地址 Kubernetes

中文社区 Kubernetes（k8s）中文文档目录_Kubernetes中文社区

Kubernetes的目标是让部署容器化的应用简单并且高效，Kubernetes一个核心特点就是能够自主的管理容器来保证云平台中的容器按照用户的期望运行。

以下是Kubernetes相关特性：

自动包装

根据资源需求和其他约束自动放置容器，同时不会牺牲可用性，混合关键和最大努力的工作负载，以提高资源利用率并节省更多资源。

横向缩放

使用简单的命令或 UI，或者根据 CPU 的使用情况自动调整应用程序副本数。

自动部署和回滚

Kubernetes 逐渐部署对应用程序或其配置的更改，同时监视应用程序运行状况，以确保它不会同时终止所有实例。如果出现问题，Kubernetes会为您恢复更改，利用日益增长的部署解决方案的生态系统。

存储编排

自动安装您所选择的存储系统，无论是本地存储，如公有云提供商 GCP 或 AWS, 还是网络存储系统 NFS,iSCSI, Gluster, Ceph, Cinder, 或 Flocker。

自我修复

重新启动失败的容器，在节点不可用时，替换和重新编排节点上的容器，终止不对用户定义的健康检查做出响应的容器，并且不会在客户端准备投放之前将其通告给客户端。

服务发现和负载均衡

不需要修改您的应用程序来使用不熟悉的服务发现机制，Kubernetes 为容器提供了自己的 IP 地址和一组容器的单个 DNS 名称，并可以在它们之间进行负载均衡。

密钥和配置管理

部署和更新密钥和应用程序配置，不会重新编译您的镜像，不会在堆栈配置中暴露密钥(secrets)。

批处理

除了服务之外，Kubernetes还可以管理您的批处理和 CI 工作负载，如果需要，替换出现故障的容器。

使用Kubernetes能做什么

Kubernetes是一个全新的基于容器技术的分布式架构领先方案（源于Brog，是google十几年经验的结晶）；

Kubernetes是一个开放的开发平台（无侵入性，现有系统很容器迁移到Kubernetes上）；

Kubernetes是一个完备的分布式系统支撑平台（完善的集群管理能力）。

使用Kubernetes可以在物理或虚拟机的Kubernetes集群上运行容器化应用，Kubernetes能够提供一个以容器为中心的基础架构，满足在生产环境中运行应用的一些常见需求，如:

多个进程协同工作
存储系统挂载
Distributing secrets
应用健康检测
应用实例的复制
Pod自动伸缩/扩展
Naming and discovering
负载均衡
滚动更新
资源监控
日志访问
调度应用程序
提供认证和授权

为什么使用Kubernetes

使用Kubernetes最直接的感受就是我们可以轻装上阵的开发复杂的系统了；其次Kubernetes是在全面拥抱微服务架构（微服务的核心就是将一个巨大的单体应用拆分成很多小的互相连接的微服务，一个微服务后面可能是多个实例副本在支撑，副本数量可以随着系统负荷的变化而动态调整）；最后Kubernetes系统架构具备超强的横向扩展能力。

1.1.2 Kubernetes快速入门

环境准备

关闭CentOS防火墙

systemctl status firewalld.service    查看防火墙是否打开

systemctl stop firewalld.service      关闭防火墙

systemctl disable firewalld.service   永久关闭防火墙

安装etcd和kubernetes软件

yum install -y etcd kubernetes

启动服务

systemctl start etcd   ==》  systemctl status etcd（查看）

systemctl start docker ==》  systemctl status docker（查看）

如果docker启动失败，请参考(vi /etc/sysconfig/selinux 把selinux后面的改为disabled，重启机器（reboot -n），再重启docker、启动服务就可以了)

systemctl start kube-apiserver

systemctl start kube-controller-manager

systemctl start kube-scheduler

systemctl start kubelet

systemctl start kube-proxy

配置（在/usr/local/k8s目录下创建文件）

Tomcat配置

创建 mytomcat.rc.yaml 文件

apiVersion: v1
kind: ReplicationController
metadata:
 name: mytomcat
spec:
 replicas: 2
 selector:
  app: mytomcat
 template:
  metadata:
   labels:
    app: mytomcat
  spec:
   containers:
    - name: mytomcat
      image: tomcat:7-jre7
      ports:
      - containerPort: 8080

创建 mytomcat.svc.yaml 文件

apiVersion: v1
kind: Service
metadata:
 name: mytomcat
spec:
 type: NodePort
 ports:
  - port: 8080
    nodePort: 30001
 selector:
  app: mytomcat

执行配置文件命令

kubectl create -f mytomcat.rc.yaml   ==》  kubectl get pods(查看)

kubectl create -f mytomcat.svc.yaml  ==》  kubectl get svc(查看)

问题解决

浏览器出不来tom猫解决办法

kubectl replace -f mytomcat.rc.yaml

kubectl delete svc

kubectl delete svc --all

kubectl create -f mytomcat.svc.yaml

docker pull失败

解决方案1 

1、yum install rhsm -y          yum install *rhsm*

2、docker pull registry.access.redhat.com/rhel7/pod-infrastructure:latest

如果以上两步解决问题了，那么就不需要在执行下面操作

3、docker search pod-infrastructure 

4、docker pull docker.io/tianyebj/pod-infrastructure 

5、docker tag tianyebj/pod-infrastructure 192.168.1.83:5000/pod-infrastructure 

6、docker push 192.168.1.83:5000/pod-infrastructure 

7、vi /etc/kubernetes/kubelet
修改 KUBELET_POD_INFRA_CONTAINER="--pod-infra-container-image=192.168.1.83:5000/pod-infrastructure:latest" 

8、重启服务
systemctl restart kube-apiserver 
systemctl restart kube-controller-manager 
systemctl restartkube-scheduler 
systemctl restart kubelet 
systemctl restart kube-proxy

解决方案2 

1、docker pull kubernetes/pause

2、docker tag docker.io/kubernetes/pause:latest 192.168.1.83:5000/google_containers/pause-amd64.3.0

3、docker push 192.168.1.83:5000/google_containers/pause-amd64.3.0

4、vi /etc/kubernetes/kubelet 
配置为 KUBELET_ARGS="--pod_infra_container_image=192.168.187.137:5000/google_containers/pause-amd64.3.0"

5、重启kubelet服务 systemctl restart kubelet

发现缺少/etc/docker/certs.d/registry.access.redhat.com/redhat-ca.crt

解决：
yum install *rhsm*

安装完成后，执行一下
docker pull registry.access.redhat.com/rhel7/pod-infrastructure:latest

如果依然报错，可参考下面的方案：
wget http://mirror.centos.org/centos/7/os/x86_64/Packages/python-rhsm-certificates-1.19.10-1.el7_4.x86_64.rpm
rpm2cpio python-rhsm-certificates-1.19.10-1.el7_4.x86_64.rpm | cpio -iv --to-stdout ./etc/rhsm/ca/redhat-uep.pem | tee /etc/rhsm/ca/redhat-uep.pem

systemctl restart docker 然后重启一下

kubectl describe pod pod名称查看pod详情

kubectl logs -f pod名称查看pod日志

外部网不能访问

在搭建好的k8s集群内创建的容器，只能在其所在的节点上curl可访问，但是在其他任何主机上无法访问容器占用的端口

解决方案：
1、vim /etc/sysctl.conf

2、最后面加上这一行：net.ipv4.ip_forward=1

解决 kubectl get pods 时No resources found

1、vim /etc/kubernetes/apiserver 

2、找到”KUBE_ADMISSION_CONTROL="-admission_control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ResourceQuota"，去掉ServiceAccount，保存退出

3、systemctl restart kube-apiserver 重启此服务

浏览测试

k8s容器,kubernetes,docker,容器

1.2 Kubernetes基本架构与常用术语

Kubernetes集群包含有节点代理kubelet和Master组件(APIs, scheduler, etc)，一切都基于分布式的存储系统。下面这张图是Kubernetes的架构图。

k8s容器,kubernetes,docker,容器

在这张系统架构图中，我们把服务分为运行在工作节点上的服务和组成集群级别控制板的服务。

Kubernetes节点有运行应用容器必备的服务，而这些都是受Master的控制。

每次个节点上当然都要运行Docker。Docker来负责所有具体的映像下载和容器运行。

Kubernetes主要由以下几个核心组件组成：

etcd 保存了整个集群的状态；

apiserver 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；

controller manager 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；

scheduler 负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；

kubelet 负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；

Container runtime 负责镜像管理以及Pod和容器的真正运行（CRI）；

kube-proxy 负责为Service提供cluster内部的服务发现和负载均衡；

除了核心组件，还有一些推荐的Add-ons：

kube-dns 负责为整个集群提供DNS服务

Ingress Controller 为服务提供外网入口

Heapster 提供资源监控

Dashboard 提供GUI

Federation 提供跨可用区的集群

Fluentd-elasticsearch 提供集群日志采集、存储与查询

Kubernetes设计理念和功能其实就是一个类似Linux的分层架构

核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境

应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）

管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略

管理（RBAC、Quota、PSP、NetworkPolicy等）

接口层：kubectl命令行工具、客户端SDK以及集群联邦

生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴

Kubernetes外部：日志、监控、配置管理、CI、CD、Workflflow、FaaS、OTS应用、ChatOps等

Kubernetes内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等

1.2.1 Cluster

Cluster是计算、存储和网络资源的集合，Kubernetes利用这些资源运行各种基于容器的应用.

Kubernetes Cluster由Master和Node组成，节点上运行着若干Kubernetes服务

1.2.2 Master

Master主要职责是调度，即决定将应用放在哪运行。Master运行Linux系统，可以是物理机或虚拟机。 Master是Kubernetes Cluster的大脑，运行着的Daemon服务包括kube-apiserver、kube-scheduler、kuber-controller-manager、etcd和Pod网络

API Serer(kube-apiserver)

API Server 提供HTTP/HTTPS RESTful API,即Kubernetes API.是Kubernetes里所有资源的CRUD等操作的唯一入口，也是集群控制的入口进程

Scheduler(kube-scheduler)

Scheduler负责资源调度的里程，简单说，它决定将Pod放在哪个Node上运行

Controller Manager(kube-controller-manager)

所有资源对象的自动化控制中心。Controller Manager负责管理Cluster各种资源，保证资源处于预期的状态。Controller Manager有多种，如replication controller、endpoints controller、namespacecontroller、serviceaccounts controller等。

不同的controller管理不同的资源，如replication controller管理Deployment、StatefulSet、DaemonSet的生命周期，namespace controller管理Namespace资源

etcd

etcd负责保存Kubernetes Cluster的配置信息和各种资源的状态信息。当数据发生变化时，etcd会快速地通知Kubernetes相关组件

Pod网络

Pod要能够相互通信，Kubernetes Cluster必须部署Pod网络，flflannel是其中一个可选方案。

1.2.2 Node

除了Master，Kubernetes集群中的其它机器被称为Node节点。Node职责是运行容器应用，Node由Master管理，Node负责监控并汇报容器的状态，同时根据Master的要求管理容器的生命周期。Node也运行在Linux系统，可以是物理机或虚拟机。

每个Node节点上都运行着以下一组关键进程

kubelet

负责Pod对应的容器的创建、启动等任务，同时与Master节点密切协作，实现集群管理的基本功能

kube-proxy

实现Kubernetes Service的通信与负载均衡机制的重要组件

Docker Enginer

Docker引擎，负责本机的容器创建和管理工作

1.2.3 Pod

Pod是Kubernetes的最小单元，也是最重要和最基本的概念。每一个Pod包含一个或多个容器，Pod的容器会作为一个整体被Master调到一个Node上运行。Kubenetes为每个Pod都分配了唯一的IP地址，称为PodIP,一个Pod里的多个容器共享PodIP地址。在Kubernetes里，一个Pod里的容器与另外主机上的Pod容器能够直接通信。

1.2.4 Service

Kubernetes Service定义了外界访问一组特定Pod的方式，Service有自己的IP和端口，Service为Pod提供了负载均衡。它也是Kubernetes最核心的资源对象之一，每个Service其实就是我们经常提起的微服务架构中的一个"微服务"。

1.2.5 Replication Controller

Replication Controller(简称RC)是Kubernetes系统中的核心概念之一，它其实是定义了一个期望的场景，即声明某种Pod的副本数量在任意时刻都符合某个预期值，所以RC的定义包括如下几个部分

Pod期待的副本数(replicas)

用于筛选目标Pod的Label Selector

当Pod的副本数量小于预期数量时，用于创建新Pod的Pod模板(template)

以下是总结的RC的一些特性与作用

在大多数情况下，我们通过定义一个RC实现Pod的创建过程及副本数量的自动控制

RC里包括完整的Pod定义模板

RC通过Label Selector机制实现对Pod副本的自动控制

通过改变RC里的Pod副本数量，可以实现Pod的扩容或缩容功能

通过改变RC里Pod模板中镜像版本，可以实现Pod的滚动升级功能

2.Kubernetes集群

Kubernetes用于协调高度可用的计算机集群，这些计算机群集被连接作为单个单元工作。Kubernetes 在一个集群上以更有效的方式自动分发和调度容器应用程序。Kubernetes集群由两种类型的资源组成：

Master是集群的调度节点
Nodes是应用程序实际运行的工作节点

接下来为大家讲解一下如何快速部署一套Kubernetes集群，K8S集群部署有几种方式：kubeadm、minikube和二进制包。前两者属于自动部署，简化部署操作，我们这里强烈推荐初学者使用二进制包部署，因为自动部署屏蔽了很多细节，使得对各个模块感知很少，非常不利用学习。

2.1环境准备与规划

推荐配置2核2G

Docker version 17.05.0-ce

角色	IP	组件
master	192.168.126.140	etcd、kube-apiserver、kube-controller-manager、 kube-scheduler、docker
node01	192.168.126.141	kube-proxy、kubelet、docker
node02	192.168.126.142	kube-proxy、kubelet、docker

查看默认防火墙状态(关闭后显示not running ,开启后显示 running)

firewall-cmd --state

关闭防火墙

systemctl stop fifirewalld.service

禁止firewall开机启动

systemctl disable firewalld.service

获取Kubernetes二进制包

kubernetes/CHANGELOG-1.9.md at master · kubernetes/kubernetes · GitHub

k8s容器,kubernetes,docker,容器

页面表格中找到Server Binaries中的kubernetes-server-linux-amd64.tar.gz文件，下载到本地。

该压缩包中包括了k8s需要运行的全部服务程序文件

2.2 Master安装

2.2.1 Docker安装

yum update

（1）设置yum源

vi /etc/yum.repos.d/docker.repo 

[dockerrepo]
name=Docker Repository
baseurl=https://yum.dockerproject.org/repo/main/centos/$releasever/
enabled=1
gpgcheck=1
gpgkey=https://yum.dockerproject.org/gpg

（2）安装docker

yum install docker-engine -y

（3）安装后查看docker版本

docker -v

2.2.2 etcd服务

etcd做为Kubernetes集群的主要服务，在安装Kubernetes各服务前需要首先安装和启动。

下载etcd二进制文件

Releases · etcd-io/etcd · GitHub

k8s容器,kubernetes,docker,容器

上传到master

可以使用lrzsz，如果没有安装，可以通过yum进行安装 yum install lrzsz

上传到 /usr/local/k8s 目录并解压

tar -zxvf etcd-v3.3.9-linux-amd64.tar.gz

进入 etcd-v3.3.9-linux-amd64 目录将etcd和etcdctl文件复制到/usr/bin目录

cp etcd etcdctl /usr/bin

配置systemd服务文件vi /usr/lib/systemd/system/etcd.service

[Unit] 
Description=Etcd Server 
After=network.target 
[Service] 
Type=simple 
EnvironmentFile=-/etc/etcd/etcd.conf 
WorkingDirectory=/var/lib/etcd/ 
ExecStart=/usr/bin/etcd 
Restart=on-failure 
[Install] 
WantedBy=multi-user.target

启动与测试etcd服务

systemctl daemon-reload 

systemctl enable etcd.service 

mkdir -p /var/lib/etcd/ 

systemctl start etcd.service 

systemctl status etcd.service 

etcdctl cluster-health

2.2.3 kube-apiserver服务

/usr/local/k8s 目录下上传 kubernetes-server-linux-amd64.tar.gz 文件并解压

tar -zxvf kubernetes-server-linux-amd64.tar.gz

解压后进入到 kubernetes/server/bin 将kube-apiserver、kube-controller-manager、kube-scheduler以及管理要使用的kubectl二进制命令文件放到/usr/bin目录，即完成这几个服务的安装。

cp kube-apiserver kube-controller-manager kube-scheduler kubectl /usr/bin/

下面是对kube-apiserver服务进行配置

编辑systemd服务文件 vi /usr/lib/systemd/system/kube-apiserver.service

[Unit] 
Description=Kubernetes API Server 
Documentation=https://github.com/kubernetes/kubernetes 
After=etcd.service 
Wants=etcd.service 
[Service] 
EnvironmentFile=/etc/kubernetes/apiserver 
ExecStart=/usr/bin/kube-apiserver $KUBE_API_ARGS 
Restart=on-failure 
Type=notify 
[Install] 
WantedBy=multi-user.target

配置文件

创建目录：mkdir /etc/kubernetes

vi /etc/kubernetes/apiserver

KUBE_API_ARGS="--storage-backend=etcd3 --etcd-servers=http://127.0.0.1:2379 --insecure-bind-address=0.0.0.0 --insecure-port=8080 --service-cluster-ip-range=169.169.0.0/16 --service-node-port-range=1-65535 --admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,Defaul tStorageClass,ResourceQuota --logtostderr=true --log-dir=/var/log/kubernetes --v=2"

2.2.4 kube-controller-manager服务

kube-controller-manager服务依赖于kube-apiserver服务：

配置systemd服务文件：vi /usr/lib/systemd/system/kube-controller-manager.service

[Unit] 
Description=Kubernetes Controller Manager 
Documentation=https://github.com/GoogleCloudPlatform/kubernetes 
After=kube-apiserver.service 
Requires=kube-apiserver.service 
[Service] 
EnvironmentFile=-/etc/kubernetes/controller-manager 
ExecStart=/usr/bin/kube-controller-manager $KUBE_CONTROLLER_MANAGER_ARGS 
Restart=on-failure 
LimitNOFILE=65536 
[Install] 
WantedBy=multi-user.target

配置文件： vi /etc/kubernetes/controller-manager

KUBE_CONTROLLER_MANAGER_ARGS="--master=http://192.168.1.83:8080 --logtostderr=true --log-dir=/var/log/kubernetes --v=2"

2.2.5 kube-scheduler服务

kube-scheduler服务也依赖于kube-apiserver服务。

配置systemd服务文件：vi /usr/lib/systemd/system/kube-scheduler.service

[Unit] 
Description=Kubernetes Scheduler 

Documentation=https://github.com/GoogleCloudPlatform/kubernetes
After=kube-apiserver.service 
Requires=kube-apiserver.service 

[Service] 
EnvironmentFile=-/etc/kubernetes/scheduler 
ExecStart=/usr/bin/kube-scheduler $KUBE_SCHEDULER_ARGS 
Restart=on-failure 
LimitNOFILE=65536 

[Install] 
WantedBy=multi-user.target

配置文件：vi /etc/kubernetes/scheduler

KUBE_SCHEDULER_ARGS="--master=http://192.168.1.83:8080 --logtostderr=true --log-dir=/var/log/kubernetes --v=2"

2.2.6 启动

完成以上配置后，按顺序启动服务

systemctl daemon-reload


systemctl enable etcd

systemctl start etcd

systemctl status etcd


systemctl enable docker

systemctl start docker

systemctl status docker


systemctl enable kube-apiserver.service

systemctl start kube-apiserver.service

systemctl status kube-apiserver.service


systemctl enable kube-controller-manager.service

systemctl start kube-controller-manager.service

systemctl status kube-controller-manager


systemctl enable kube-scheduler.service

systemctl start kube-scheduler.service

systemctl status kube-scheduler.service

检查每个服务的健康状态：

systemctl status kube-apiserver.service

systemctl status kube-controller-manager.service

systemctl status kube-scheduler.service

2.3 Node1 安装

在Node1节点上，以同样的方式把从压缩包中解压出的二进制文件kubelet kube-proxy放到/usr/bin目录中。

/usr/local/k8s 目录进入到这个目录里面：

cd kubernetes/server/bin

复制：

cp kubelet kube-proxy /usr/bin

在Node1节点上需要预先安装docker,请参考Master上Docker的安装，并启动Docker

yum install docker-engine -y

systemctl enable docker

systemctl start docker

systemctl status docker

2.3.1 kubelet服务

配置systemd服务文件：vi /usr/lib/systemd/system/kubelet.service

[Unit] 

Description=Kubernetes Kubelet Server
Documentation=https://github.com/GoogleCloudPlatform/kubernetes 
After=docker.service 
Requires=docker.service 

[Service] 
WorkingDirectory=/var/lib/kubelet 
EnvironmentFile=-/etc/kubernetes/kubelet 
ExecStart=/usr/bin/kubelet $KUBELET_ARGS 
Restart=on-failure 
KillMode=process 

[Install] 
WantedBy=multi-user.target

mkdir -p /var/lib/kubelet

配置文件：vi /etc/kubernetes/kubelet

KUBELET_ARGS="--kubeconfig=/etc/kubernetes/kubeconfig --hostname-override=192.168.1.83 --logtostderr=false --log-dir=/var/log/kubernetes --v=2 --fail-swap-on=false"

用于kubelet连接Master Apiserver的配置文件

vi /etc/kubernetes/kubeconfifig

apiVersion: v1 
kind: Config 
clusters: 
  - cluster: 
      server: http://192.168.1.83:8080 
    name: local 
contexts: 
  - context: 
      cluster: local 
    name: mycontext 
current-context: mycontext

2.3.2 kube-proxy 服务

kube-proxy服务依赖于network服务,所以一定要保证network服务正常，如果network服务启动失败，常见解决方

案有以下几中：

1.和 NetworkManager 服务有冲突，这个好解决，直接关闭 NetworkManger 服务就好了，service NetworkManager stop，并且禁止开机启动 chkconfig NetworkManager off 。之后重启就好了 

2.和配置文件的MAC地址不匹配，这个也好解决，使用ip addr（或ifconfig）查看mac地址，将/etc/sysconfig/network-scripts/ifcfg-xxx中的HWADDR改为查看到的mac地址 

3.设定开机启动一个名为NetworkManager-wait-online服务，命令为：systemctl enable NetworkManager-wait-online.service 

4.查看/etc/sysconfig/network-scripts下，将其余无关的网卡位置文件全删掉，避免不必要的影响，即只留一个以ifcfg开头的文件

配置systemd服务文件：vi /usr/lib/systemd/system/kube-proxy.service

[Unit] 
Description=Kubernetes Kube-proxy Server 
Documentation=https://github.com/GoogleCloudPlatform/kubernetes 
After=network.service 
Requires=network.service 

[Service] 
EnvironmentFile=/etc/kubernetes/proxy 
ExecStart=/usr/bin/kube-proxy $KUBE_PROXY_ARGS 
Restart=on-failure 
LimitNOFILE=65536 
KillMode=process 

[Install] 
WantedBy=multi-user.target

配置文件：vi /etc/kubernetes/proxy

KUBE_PROXY_ARGS="--master=http://192.168.1.83:8080 --hostname override=192.168.1.84 --logtostderr=true --log-dir=/var/log/kubernetes --v=2"

2.3.3 启动

systemctl daemon-reload

systemctl start docker

systemctl status docker

systemctl enable kubelet

systemctl start kubelet

systemctl status kubelet

systemctl enable kube-proxy

systemctl start kube-proxy

systemctl status kube-proxy

2.4 Node2 安装

参考Node1安装，注意修改IP

k8s容器,kubernetes,docker,容器

2.5 健康检查与示例测试

查看集群状态

kubectl get nodes

查看master集群组件状态

kubectl get cs

/usr/local/k8s 下创建文件 nginx-rc.yaml nginx-svc.yaml

nginx-rc.yaml

apiVersion: v1 
kind: ReplicationController 
metadata: 
 name: nginx 
spec: 
 replicas: 3 
 selector: 
  app: nginx 
 template: 
  metadata: 
   labels: 
    app: nginx 
  spec: 
   containers: 
   - name: nginx 
   image: nginx 
   ports: 
   - containerPort: 80

kubectl create -f nginx-rc.yaml

kubectl create -f nginx-svc.yaml

nginx-svc.yaml

apiVersion: v1 
kind: Service 
metadata: 
 name: nginx 
spec: 
 type: NodePort 
 ports: 
  - port: 80 
    nodePort: 33333 
 selector: 
 app: nginx

查看pod

kubectl get pods

查看具体pod详情

kubectl describe pods nginx-ml7qc

私有仓库搭建

docker pull registry

docker run -di --name=registry -p 5000:5000 registry

修改daemon.json {"insecure-registries":["192.168.126.148:5000"]}

重启docker服务 systemctl restart docker

k8s容器,kubernetes,docker,容器

总结

1.K8S架构和组件

k8s容器,kubernetes,docker,容器

1.1 Master

Kubernetes API Server

作为Kubernetes系统的入口，其封装了核心对象的增删改查操作，以RESTful API接口方式提供给外部客户和内部组件调用。维护的REST对象持久化到Etcd中存储。
Kubernetes Scheduler 为新建立的Pod进行节点(node)选择(即分配机器)，负责集群的资源调度。组件抽离，可以方便替换成其他调度器。
Kubernetes Controller

负责执行各种控制器，目前已经提供了很多控制器来保证Kubernetes的正常运行。
Replication Controller

管理维护Replication Controller，关联Replication Controller和Pod，保证Replication Controller定义的副本数量与实际运行Pod数量一致。

1.2 Node

Kubelet

负责管控容器，Kubelet会从Kubernetes API Server接收Pod的创建请求，启动和停止容器，监控容器运行状态并汇报给Kubernetes API Server。

Kubernetes Proxy

负责为Pod创建代理服务，Kubernetes Proxy会从Kubernetes API Server获取所有的Service信息，并根据Service的信息创建代理服务，实现Service到Pod的请求路由和转发，从而实现Kubernetes层级的虚拟转发网络。

Docker

Node上需要运行容器服务

2.K8S集群搭建常见问题

解决 kubectl get pods时No resources found问题

1、vim /etc/kubernetes/apiserver

2、找到”KUBE_ADMISSION_CONTROL="- admission_control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota"，去掉ServiceAccount，保存退出。

3、systemctl restart kube-apiserver 重启此服务

pull 失败

解决方案1

1、yum install rhsm -y yum install *rhsm*

2、docker pull registry.access.redhat.com/rhel7/pod-infrastructure:latest

如果以上两步解决问题了，那么就不需要在执行下面操作

3、docker search pod-infrastructure

4、docker pull docker.io/tianyebj/pod-infrastructure

5、docker tag tianyebj/pod-infrastructure 192.168.126.143:5000/pod-infrastructure

6、docker push 192.168.126.143:5000/pod-infrastructure

7、vi /etc/kubernetes/kubelet

修改 KUBELET_POD_INFRA_CONTAINER="--pod-infra-container-image=192.168.126.143:5000/pod- infrastructure:latest"

8、重启服务

                systemctl restart kube-apiserver

                systemctl restart kube-controller-manager

                systemctl restart kube-scheduler

                systemctl restart kubelet systemctl

                restart kube-proxy

解决方案2

1、docker pull kubernetes/pause

2、docker tag docker.io/kubernetes/pause:latest 192.168.126.143:5000/google_containers/pause-amd64.3.0

3、docker push 192.168.126.143:5000/google_containers/pause-amd64.3.0

4、vi /etc/kubernetes/kubelet配置为

KUBELET_ARGS="--pod_infra_container_image=192.168.126.143:5000/google_containers/pause-amd64.3.0"

5、重启kubelet服务 systemctl restart kubelet

3.常用命令

获取当前命名空间下的容器

kubectl get pods
获取所有容器l列表

kubectl get all
创建容器

kubectl create -f kubernate-pvc.yaml
删除容器

kubectl delete pods/test-pd 或者 kubectl delete -f rc-nginx.yaml
查看指定pod跑在哪个node上

kubectl get pod /test-pd -o wide
查看容器日志

Kubectl logs nginx-8586cf59-mwwtc

kubectl describe pods nginx-8586cf59-mwwtc
进入容器终端命令

kubectl exec -it nginx-8586cf59-mwwtc /bin/bash
一个Pod里含有多个容器用--container or -c 参数。

例如:假如这里有个Pod名为my-pod,这个Pod有两个容器,分别名为main-app 和 helper-app,下面的命令将打开到main-app的shell的容器里。

kubectl exec -it my-pod --container main-app -- /bin/bash
容器详情列表

kubectl describe pod/mysql- m8rbl
查看容器状态

kubectl get svc

容器化进阶Kubernetes核心技术

1 Pod 详解

Pod是Kubernetes的最重要概念，每一个Pod都有一个特殊的被称为”根容器“的Pause容器。Pause容器对应的镜像属于Kubernetes平台的一部分，除了Pause容器，每个Pod还包含一个或多个紧密相关的用户业务容器。

k8s容器,kubernetes,docker,容器

Pod vs 应用

每个Pod都是应用的一个实例，有专用的IP

Pod vs 容器

一个Pod可以有多个容器，彼此间共享网络和存储资源，每个Pod 中有一个Pause容器保存所有的容器状态，通过管理pause容器，达到管理pod中所有容器的效果

Pod vs 节点

同一个Pod中的容器总会被调度到相同Node节点，不同节点间Pod的通信基于虚拟二层网络技术实现

Pod vs Pod

普通的Pod和静态Pod

1.1 Pod 的定义

下面是yaml文件定义的Pod的完整内容

apiVersion: v1              //版本 
kind: Pod                   //类型，pod 
metadata:                   //元数据 
  name: string              //元数据，pod的名字 
  namespace: string         //元数据，pod的命名空间 
  labels:                   //元数据，标签列表 
	- name: string          //元数据，标签的名字 
  annotations:              //元数据,自定义注解列表 
    - name: string          //元数据,自定义注解名字 
spec:                      //pod中容器的详细定义
    containers:             //pod中的容器列表，可以有多个容器 
    - name: string          //容器的名称 
	image: string           //容器中的镜像 
	imagesPullPolicy: [Always|Never|IfNotPresent]       //获取镜像的策略，默认值为Always，每次都尝试重新下载镜像
	command: [string]       //容器的启动命令列表（不配置的话使用镜像内部的命令） 
	args: [string]          //启动参数列表 
	workingDir: string      //容器的工作目录 
	volumeMounts:           //挂载到到容器内部的存储卷设置 
	- name: string 
	  mountPath: string     //存储卷在容器内部Mount的绝对路径 
      readOnly: boolean     //默认值为读写 
    ports:                  //容器需要暴露的端口号列表 
	- name: string 
	  containerPort: int    //容器要暴露的端口 
	  hostPort: int         //容器所在主机监听的端口（容器暴露端口映射到宿主机的端口，设置hostPort时同一台宿主机将不能再启动该容器的第2份副本） 
	  protocol: string      //TCP和UDP，默认值为TCP 
	env:                    //容器运行前要设置的环境列表 
	- name: string 
	  value: string 
	resources: 
	  limits:               //资源限制，容器的最大可用资源数量 
	    cpu: Srting 
	    memory: string 
	  requeste:              //资源限制，容器启动的初始可用资源数量 
	    cpu: string 
	    memory: string 
	livenessProbe:           //pod内容器健康检查的设置 
	  exec: 
		command: [string]    //exec方式需要指定的命令或脚本 
	  httpGet:               //通过httpget检查健康 
		path: string 
		port: number 
		host: string 
		scheme: Srtring 
		httpHeaders: 
		- name: Stirng 
		  value: string 
	  tcpSocket:                //通过tcpSocket检查健康 
		port: number 
	  initialDelaySeconds: 0    //首次检查时间 
	  timeoutSeconds: 0         //检查超时时间 
	  periodSeconds: 0          //检查间隔时间 
	  successThreshold: 0 
	  failureThreshold: 0 
	  securityContext:          //安全配置 
		privileged: falae 
	restartPolicy: [Always|Never|OnFailure]   //重启策略，默认值为Always 
	nodeSelector: object                      //节点选择，表示将该Pod调度到包含这些label的Node上，以key:value格式指定 
	imagePullSecrets: 
	- name: string 

	hostNetwork: false                        //是否使用主机网络模式，弃用Docker网桥，默认否
  volumes:                                    //在该pod上定义共享存储卷列表 
  - name: string 
    emptyDir: {}                              //是一种与Pod同生命周期的存储卷，是一个临时目录，内容为空 
    hostPath:                                 //Pod所在主机上的目录，将被用于容器中mount的目录 
      path: string 
    secret:                                   //类型为secret的存储卷 
      secretName: string 
      item: 
      - key: string 
      	path: string 
     configMap:                               //类型为configMap的存储卷 
       name: string 
       items: 
       - key: string 
         path: string

1.2 Pod的基本用法

在kubernetes中对运行容器的要求为：容器的主程序需要一直在前台运行，而不是后台运行。应用需要改造成前台运行的方式。如果我们创建的Docker镜像的启动命令是后台执行程序，则在kubelet创建包含这个容器的pod之后运行完该命令，即认为Pod已经结束，将立刻销毁该Pod。如果为该Pod定义了RC，则创建、销毁会陷入一个无限循环的过程中。

Pod可以由1个或多个容器组合而成。

由一个容器组成的Pod示例

# 一个容器组成的Pod 
apiVersion: v1 
kind: Pod 
metadata: 
  name: mytomcat 
  labels: 
	name: mytomcat 
spec: 
  containers: 
  - name: mytomcat 
	image: tomcat 
	ports: 
	- containerPort: 8000

由两个为紧耦合的容器组成的Pod示例

#两个紧密耦合的容器 
apiVersion: v1 
kind: Pod 
metadata: 
  name: myweb 
  labels: 
	name: tomcat-redis
spec: 
  containers: 
  - name: tomcat 
	image: tomcat 
	ports: 
	- containerPort: 8080 
  - name: redis 
	image: redis 
	ports: 
	- containerPort: 6379

创建

kubectl create -f xxx.yaml

查看

kubectl get pod/po <Pod_name> 

kubectl get pod/po <Pod_name> -o wide 

kubectl describe pod/po <Pod_name>

删除

kubectl delete -f pod pod_name.yaml 

kubectl delete pod --all/[pod_name]

1.3 Pod 的分类

Pod有两种类型

普通Pod

普通Pod一旦被创建，就会被放入到etcd中存储，随后会被Kubernetes Master调度到某个具体的Node上并进行绑定，随后该Pod对应的Node上的kubelet进程实例化成一组相关的Docker容器并启动起来。在默认情况下，当Pod里某个容器停止时，Kubernetes会自动检测到这个问题并且重新启动这个Pod里某所有容器，如果Pod所在的Node宕机，则会将这个Node上的所有Pod重新调度到其它节点上。

静态Pod

静态Pod是由kubelet进行管理的仅存在于特定Node上的Pod,它们不能通过 API Server进行管理，无法与ReplicationController、Deployment或DaemonSet进行关联，并且kubelet也无法对它们进行健康检查。

1.4 Pod 生命周期和重启策略

Pod的状态

状态值	说明
Pending	API Server已经创建了该Pod,但Pod中的一个或多个容器的镜像还没有创建，包括镜像下载过程
Running	Pod内所有容器已创建，且至少一个容器处于运行状态、正在启动状态或正在重启状态
Completed	Pod内所有容器均成功执行退出，且不会再重启
Failed	Pod内所有容器均已退出，但至少一个容器退出失败
Unknown	由于某种原因无法获取Pod状态，例如网络通信不畅

Pod重启策略

Pod的重启策略包括Always、OnFailure和Never，默认值是Always

重启策略	说明
Always	当容器失效时，由kubelet自动重启该容器
OnFailure	当容器终止运行且退出码不为0时，由kubelet自动重启该容器
Never	不论容器运行状态如何，kubelet都不会重启该容器

常见状态转换

Pod包含的容器数	Pod当前的状态	发生事件	Pod的结果状态
			RestartPolicy=Always	RestartPolicy=OnFailure	RestartPolicy=Never
包含一个容器	Running	容器成功退出	Running	Succeeded	Succeeded
包含一个容器	Running	容器成失败退出	Running	Running	Failure
包含两个容器	Running	1个容器失败退出	Running	Running	Running
包含两个容器	Running	容器被OOM杀掉	Running	Running	Failure

1.5 Pod资源配置

每个Pod都可以对其能使用的服务器上的计算资源设置限额，Kubernetes中可以设置限额的计算资源有CPU与Memory两种，其中CPU的资源单位为CPU数量,是一个绝对值而非相对值。Memory配额也是一个绝对值，它的单位是内存字节数。

Kubernetes里，一个计算资源进行配额限定需要设定以下两个参数：

Requests 该资源最小申请数量，系统必须满足要求
Limits 该资源最大允许使用的量，不能突破，当容器试图使用超过这个量的资源时，可能会被Kubernetes Kill并重启

sepc
  containers: 
  - name: db 
	image: mysql 
	resources: 
	  requests: 
		memory: "64Mi" 
		cpu: "250m" 
	  limits: 
		memory: "128Mi" 
		cpu: "500m"

上述代码表明MySQL容器申请最少0.25个CPU以及64MiB内存，在运行过程中容器所能使用的资源配额为0.5个CPU以及128MiB内存。

2 Label详解

Label是Kubernetes系统中另一个核心概念。一个Label是一个key=value的键值对，其中key与value由用户自己指定。Label可以附加到各种资源对象上，如Node、Pod、Service、RC，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上，Label通常在资源对象定义时确定，也可以在对象创建后动态添加或删除。

Label的最常见的用法是使用metadata.labels字段，来为对象添加Label，通过spec.selector来引用对象

apiVersion: v1 
kind: ReplicationController 
metadata: 
  name: nginx 
spec: 
  replicas: 3 
  selector: 
	app: nginx 
  template: 
	metadata: 
	  labels: 
		app: nginx 
	spec: 
	  containers: 
	  - name: nginx 
	  image: nginx 
	  ports: 
	- containerPort: 80 
------------------------------------- 
apiVersion: v1 
kind: Service 
metadata: 
  name: nginx 
spec:
  type: NodePort 
  ports: 
	- port: 80 
    nodePort: 3333 
  selector: 
	app: nginx

Label附加到Kubernetes集群中的各种资源对象上，目的就是对这些资源对象进行分组管理，而分组管理的核心就是Label Selector。Label与Label Selector都是不能单独定义，必须附加在一些资源对象的定义文件上，一般附加在RC和Service的资源定义文件中。

3 Replication Controller详解

Replication Controller(RC)是Kubernetes系统中核心概念之一，当我们定义了一个RC并提交到Kubernetes集群中以后，Master节点上的Controller Manager组件就得到通知，定期检查系统中存活的Pod,并确保目标Pod实例的数量刚好等于RC的预期值，如果有过多或过少的Pod运行，系统就会停掉或创建一些Pod.此外我们也可以通过修改RC的副本数量，来实现Pod的动态缩放功能。

kubectl scale rc nginx --replicas=5

由于Replication Controller与Kubernetes代码中的模块Replication Controller同名，所以在Kubernetes v1.2时，它就升级成了另外一个新的概念Replica Sets,官方解释为下一代的RC，它与RC区别是:Replica Sets支援基于集合的Label selector,而RC只支持基于等式的Label Selector。我们很少单独使用Replica Set,它主要被Deployment这个更高层面的资源对象所使用，从而形成一整套Pod创建、删除、更新的编排机制。最好不要越过RC直接创建Pod，因为Replication Controller会通过RC管理Pod副本，实现自动创建、补足、替换、删除Pod副本，这样就能提高应用的容灾能力，减少由于节点崩溃等意外状况造成的损失。即使应用程序只有一个Pod副本，也强烈建议使用RC来定义Pod

4 Replica Set详解

ReplicaSet 跟 ReplicationController 没有本质的不同，只是名字不一样，并且 ReplicaSet 支持集合式的

selector（ReplicationController 仅支持等式）。Kubernetes官方强烈建议避免直接使用ReplicaSet，而应该通过

Deployment来创建RS和Pod。由于ReplicaSet是ReplicationController的代替物，因此用法基本相同，唯一的区

别在于ReplicaSet支持集合式的selector。

5 Deployment详解

Deployment是Kubenetes v1.2引入的新概念，引入的目的是为了更好的解决Pod的编排问题，Deployment内部使用了Replica Set来实现。Deployment的定义与Replica Set的定义很类似，除了API声明与Kind类型有所区别：

apiVersion: extensions/v1beta1 
kind: Deployment 
metadata: 
  name: frontend 
spec: 
  replicas: 1 
  selector: 
	
	matchLabels:
	  tier: frontend 
	matchExpressions: 
	  - {key: tier, operator: In, values: [frontend]} 
  template: 
	metadata: 
	  labels: 
		app: app-demo 
		tier: frontend 
	spec: 
	  containers: 
	  - name: tomcat-demo 
		image: tomcat 
		ports: 
		- containerPort: 8080

6 Horizontal Pod Autoscaler

Horizontal Pod Autoscal(Pod横向扩容简称HPA)与RC、Deployment一样，也属于一种Kubernetes资源对象。通过追踪分析RC控制的所有目标Pod的负载变化情况，来确定是否需要针对性地调整目标Pod的副本数，这是HPA的实现原理。

Kubernetes对Pod扩容与缩容提供了手动和自动两种模式，手动模式通过kubectl scale命令对一个Deployment/RC进行Pod副本数量的设置。自动模式则需要用户根据某个性能指标或者自定义业务指标，并指定Pod副本数量的范围，系统将自动在这个范围内根据性能指标的变化进行调整。

手动扩容和缩容

kubectl scale deployment frontend --replicas 1

自动扩容和缩容

HPA控制器基本Master的kube-controller-manager服务启动参数 --horizontal-pod-autoscaler-sync-period定义的时长(默认值为30s),周期性地监测Pod的CPU使用率，并在满足条件时对RC或Deployment中的Pod副本数量进行调整，以符合用户定义的平均Pod CPU使用率。

apiVersion: extensions/v1beta1 
kind: Deployment 
metadata: 
  name: nginx-deployment 
spec: 
  replicas: 1 
  template: 
	metadata: 
	  name: nginx 
	  labels: 
		app: nginx 
	spec: 
	  containers: 
	  - name: nginx 
	  image: nginx 
	  
	  resources:
	  requests: 
	  	cpu: 50m 
	ports: 
	- containerPort: 80 
------------------------------- 
apiVersion: v1 
kind: Service 
metadata: 
  name: nginx-svc 
spec: 
  ports: 
  - port: 80 
  selector: 
	app: nginx 
----------------------------------- 
apiVersion: autoscaling/v1 
kind: HorizontalPodAutoscaler 
metadata: 
  name: nginx-hpa 
spec: 
  scaleTargetRef: 
	apiVersion: app/v1beta1 
	kind: Deployment 
	name: nginx-deployment 
  minReplicas: 1 
  maxReplicas: 10 
  targetCPUUtilizationPercentage: 50

7 Volume详解

Volume是Pod中能够被多个容器访问的共享目录。Kubernetes的Volume定义在Pod上，它被一个Pod中的多个容器挂载到具体的文件目录下。Volume与Pod的生命周期相同，但与容器的生命周期不相关，当容器终止或重启时，Volume中的数据也不会丢失。要使用volume，pod需要指定volume的类型和内容（ spec.volumes 字段），和映射到容器的位置（ spec.containers.volumeMounts 字段）。 Kubernetes支持多种类型的Volume,包括：emptyDir、hostPath、gcePersistentDisk、awsElasticBlockStore、nfs、iscsi、flflocker、glusterfs、rbd、cephfs、gitRepo、secret、persistentVolumeClaim、downwardAPI、azureFileVolume、azureDisk、vsphereVolume、Quobyte、PortworxVolume、ScaleIO。

emptyDir

EmptyDir类型的volume创建于pod被调度到某个宿主机上的时候，而同一个pod内的容器都能读写EmptyDir中的同一个文件。一旦这个pod离开了这个宿主机，EmptyDir中的数据就会被永久删除。所以目前EmptyDir类型的volume主要用作临时空间，比如Web服务器写日志或者tmp文件需要的临时目录。yaml示例如下

apiVersion: v1 
kind: Pod 
metadata: 
  name: test-pd 
spec: 
  containers: 
	- image: docker.io/nazarpc/webserver 
	name: test-container
	volumeMounts: 
	- mountPath: /cache 
	  name: cache-volume 
  volumes: 
  - name: cache-volume 
	emptyDir: {}

hostPath

HostPath属性的volume使得对应的容器能够访问当前宿主机上的指定目录。例如，需要运行一个访问Docker系统目录的容器，那么就使用/var/lib/docker目录作为一个HostDir类型的volume；或者要在一个容器内部运行CAdvisor，那么就使用/dev/cgroups目录作为一个HostDir类型的volume。一旦这个pod离开了这个宿主机，HostDir中的数据虽然不会被永久删除，但数据也不会随pod迁移到其他宿主机上。因此，需要注意的是，由于各个宿主机上的文件系统结构和内容并不一定完全相同，所以相同pod的HostDir可能会在不

同的宿主机上表现出不同的行为。yaml示例如下：

apiVersion: v1 
kind: Pod 
metadata: 
  name: test-pd 
spec: 
  containers: 
	- image: docker.io/nazarpc/webserver 
	  name: test-container 
	  # 指定在容器中挂接路径 
	  volumeMounts: 
	  - mountPath: /test-pd 
		name: test-volume 
	# 指定所提供的存储卷 
	volumes: 
	- name: test-volume 
	  # 宿主机上的目录 
	  hostPath: 
		# directory location on host 
		path: /data

NFS类型的volume。允许一块现有的网络硬盘在同一个pod内的容器间共享。yaml示例如下：

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 
kind: Deployment 
metadata: 
  name: redis 
spec: 
  selector: 
	matchLabels: 
	  app: redis 
  revisionHistoryLimit: 2 
  template: 
	metadata: 
	  labels:
		app: redis 
	spec: 
	  containers: 
	  # 应用的镜像 
	  - image: redis 
		name: redis 
		imagePullPolicy: IfNotPresent 
		# 应用的内部端口 
		ports: 
		- containerPort: 6379 
	  	  name: redis6379 
		env: 
		- name: ALLOW_EMPTY_PASSWORD 
	  		value: "yes" 
		- name: REDIS_PASSWORD 
	  		value: "redis" 
		# 持久化挂接位置，在docker中 
		volumeMounts: 
		- name: redis-persistent-storage 
	  	  mountPath: /data 
	  volumes: 
      # 宿主机上的目录 
	  - name: redis-persistent-storage 
		nfs:
		path: /k8s-nfs/redis/data 
		server: 192.168.126.112

8 Namespace详解

Namespace在很多情况下用于实现多用户的资源隔离，通过将集群内部的资源对象分配到不同的Namespace中，形成逻辑上的分组，便于不同的分组在共享使用整个集群的资源同时还能被分别管理。Kubernetes集群在启动后，会创建一个名为"default"的Namespace，如果不特别指明Namespace,则用户创建的Pod，RC，Service都将被系统创建到这个默认的名为default的Namespace中。

Namespace创建

apiVersion: v1 
kind: Namespace 
metadata: 
  name: development 
--------------------- 
apiVersion: v1 
kind: Pod 
metadata: 
  name: busybox 
  namespace: development 
spec: 
  containers: 
  - image: busybox 
	command: 
	  - sleep
	  - "3600" 
	name: busybox

Namespace查看

kubectl get pods --namespace=development

9 Service 详解

Service是Kubernetes最核心概念，通过创建Service,可以为一组具有相同功能的容器应用提供一个统一的入口地址，并且将请求负载分发到后端的各个容器应用上。

9.1 Service的定义

yaml格式的Service定义文件

apiVersion: v1 
kind: Service 
matadata: 
  name: string 
  namespace: string 
  labels: 
  - name: string 
  annotations: 
  - name: string 
spec: 
  selector: [] 
  type: string 
  clusterIP: string 
  sessionAffinity: string 
  ports: 
  - name: string 
	protocol: string 
	port: int 
	targetPort: int 
	nodePort: int 
  status: 
	loadBalancer: 
	  ingress: 
		ip: string 
		hostname: string

属性名称	取值类型	是否必选	取值说明
version	string	Required	v1
kind	string	Required	Service
metadata	object	Required	元数据
metadata.name	string	Required	Service名称
metadata.namespace	string	Required	命名空间，默认为default
metadata.labels[]	list		自定义标签属性列表
metadata.annotation[]	list		自定义标签属性列表
spec	object	Required	详细描述
spec.selector[]	list	Required	Label Selector配置，将选择具有指定 Label标签的Pod作为管理范围
spec.type	string	Required	Service的类型，指定Service的访问方式，默认值为ClusterIP。取值范围如下：ClusterIP: 虚拟服务的IP，用于k8s集群内部的pod访问，在Node上kube-proxy通过设置的Iptables规则进行转发。NodePort：使用宿主机的端口，使用能够访问各Node的外部客户端通过Node的IP地址和端口就能访问服务。LoadBalancer: 使用外接负载均衡器完成到服务的负载分发，需要在spec.status.loadBalancer字段指定外部负载均衡器的IP地址，并同时定义nodePort和clusterIP，用于公有云环境。
spec.clusterIP	string	Required	虚拟服务的IP地址，当type=clusterIP时，如果不指定，则系统进行自动分配。也可以手工指定。当 type=LoadBalancer时，则需要指定。
spec.sessionAffiffiffinity	string		是否支持Session，可选值为ClientIP，表示将同一个源IP地址的客户端访问请求都转发到同一个后端Pod。默认值为空。
spec.ports[]	list		Service需要暴露的端口列表
spec.ports[].name	string		端口名称
spec.ports[].protocol	string		端口协议，支持TCP和UDP，默认值为TCP
spec.ports[].port	int		服务监听的端口号
spec.ports[].targetPort	int		需要转发到后端Pod的端口号
spec.ports[].nodePort	int		当spec.type=NodePort时，指定映射到物理机的端口号
status	object		当spec.type=LoadBalancer时，设置外部负载均衡器的地址，用于公有云环境
status.loadBalancer	object		外部负载均衡器
status.loadBalancer.ingress	object		外部负载均衡器
status.loadBalancer.ingress.ip	string		外部负载均衡器的IP地址
status.loadBalancer.ingress.hostname	string		外部负载均衡器主机名

9.2 Service的基本用法

一般来说，对外提供服务的应用程序需要通过某种机制来实现，对于容器应用最简便的方式就是通过TCP/IP机制及监听IP和端口号来实现。创建一个基本功能的Service

apiVersion: v1 
kind: ReplicationController 
metadata: 
  name: mywebapp 
spec: 
  replicas: 2 
  template: 
	metadata: 
	  name: mywebapp 
	  labels: 
		app: mywebapp 
	spec: 
	  containers: 
	  - name: mywebapp 
	  image: tomcat 
	  ports: 
	  - containerPort: 8080

我们可以通过kubectl get pods -l app=mywebapp -o yaml | grep podIP来获取Pod的IP地址和端口号来访问Tomcat服务，但是直接通过Pod的IP地址和端口访问应用服务是不可靠的，因为当Pod所在的Node发生故障时，Pod将被kubernetes重新调度到另一台Node，Pod的地址会发生改变。我们可以通过配置文件来定义Service，再通过kubectl create来创建，这样可以通过Service地址来访问后端Pod.

apiVersion: v1 
kind: Service 
metadata: 
  name: mywebAppService 
spec: 
  ports: 
  - port: 8081 
	targetPort: 8080 
  selector: 
	app: mywebapp

9.2.1 多端口Service

有时一个容器应用也可能需要提供多个端口的服务，那么在Service的定义中也可以相应地设置为将多个端口对应到多个应用服务。

apiVersion: v1 
kind: Service 
metadata: 
  name: mywebAppService 
spec: 
  ports: 
  - port: 8080 
	targetPort: 8080 
	name: web 
  - port: 8005 
	targetPort: 8005 
	name: management 
  selector: 
	app: mywebapp

9.2.2 外部服务Service

在某些特殊环境中，应用系统需要将一个外部数据库作为后端服务进行连接，或将另一个集群或Namespace中的服务作为服务的后端，这时可以通过创建一个无Label Selector的Service来实现。文章来源地址https://www.toymoban.com/news/detail-744829.html

apiVersion: v1 
kind: Service 
metadata: 
  name: my-service 
spec: 
  ports: 
  - protocol: TCP 
	port: 80 
	targetPort: 80 
-------------------------- 
apiVersion: v1
kind: Endpoints 
metadata: 
  name: my-service 
subsets: 
- addresses: 
  - IP: 10.254.74.3 
  ports: 
  - port: 8080

到了这里，关于容器化进阶Kubernetes（K8S）详解的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！