kubectl create secret tls ingress-secret-fengjian --key /data/sslkey/cinyi.key --cert /data/sslkey/cinyi.pem
[root@k8s1 ingress]# vim ingress.yaml apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: nginx-default
spec:
rules:
- host: nginx.cinyi.com
http:
paths:
- backend:
serviceName: nginx-default
servicePort: [root@k8s1 ingress]# vim ingress_443.yaml apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: nginx-default-
namespace: default
spec:
tls:
- hosts:
- nginx.cinyi.com
secretName: ingress-secret
rules:
- host: nginx.cinyi.com
http:
paths:
- backend:
serviceName: nginx-default
servicePort: kubectl create secret tls ingress-secret-fengjian --key /data/sslkey/cinyi.key --cert /data/sslkey/cinyi.pem --namespace=fengjian [root@k8s1 ingress]# vim ingress-fengjian.yaml apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: nginx-fengjian-
namespace: fengjian
spec:
rules:
- host: feng.cinyi.com
http:
paths:
- backend:
serviceName: my-nginx-fengjian
servicePort: [root@k8s1 ingress]# vim ingress-fengjian-.yaml apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: nginx-fengjian-
namespace: fengjian
spec:
tls:
- hosts:
- feng.cinyi.com
secretName: ingress-secret-fengjian
rules:
- host: feng.cinyi.com
http:
paths:
- backend:
serviceName: my-nginx-fengjian
servicePort: 80

Pod的liveness和readiness

Kubelet使用liveness probe(存活探针)来确定何时重启容器。例如,当应用程序处于运行状态但无法做进一步操作,liveness探针将捕获到deadlock,重启处于该状态下的容器.

Kubelet使用readiness probe(就绪探针)来确定容器是否已经就绪可以接受流量。只有当Pod中的容器都处于就绪状态时kubelet才会认定该Pod处于就绪状态。该信号的作用是控制哪些Pod应该作为service的后端. 如果Pod处于非就绪状态,那么它们将会被从service的load balancer中移除。

 

配置活力和准备探测器

此页面显示如何为容器配置活动和准备探测。

kubelet使用活跃度探头知道什么时候重新启动的容器。例如,活动探测器可能会遇到一个应用程序正在运行但无法取得进展的僵局。在这种状态下重新启动容器可以帮助使应用程序更加可用,尽管有错误。

kubelet使用准备探测来知道容器何时准备开始接受流量。当所有容器都准备就绪时,Pod已被准备好了。该信号的一个用途是控制哪些Pod被用作服务的后端。当Pod尚未准备就绪时,它将从服务负载平衡器中删除。

在你开始之前

您需要有一个Kubernetes集群,并且kubectl命令行工具必须配置为与您的集群进行通信。如果您还没有一个集群,您可以使用Minikube创建一个集群,也 可以使用这些Kubernetes操场之一:

您的Kubernetes服务器必须是版本或更高版本。要检查版本,请输入kubectl version

定义一个活跃命令

许多长时间运行的应用程序最终会转换到断开状态,除非重新启动,否则无法恢复。Kubernetes提供活动探测器来检测和补救这种情况。

在本练习中,您将创建一个基于gcr.io/google_containers/busybox图像运行容器的Pod 。这是Pod的配置文件:

apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: gcr.io/google_containers/busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep ; rm -rf /tmp/healthy; sleep
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds:
periodSeconds:

当容器启动时,它将执行此命令:在配置文件中,您可以看到Pod有一个容器。该periodSeconds字段指定kubelet应每5秒执行一次活动探测。该initialDelaySeconds字段告诉kubelet它应该等待5秒钟,然后执行第一个探测。要执行探测,kubelet将cat /tmp/healthy在Container中执行命令。如果命令成功,则返回0,并且kubelet认为容器是活的和健康的。如果命令返回非零值,那么kubelet会杀死Container并重新启动它。

/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"

在集装箱生活的前30秒,有一个/tmp/healthy文件。所以在前30秒,命令cat /tmp/healthy返回成功代码。30秒后,cat /tmp/healthy返回失败代码。

创建荚:

kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/exec-liveness.yaml

在30秒内查看荚事件:

kubectl describe pod liveness-exec

输出表示没有活性探针失败:

FirstSeen    LastSeen    Count   From            SubobjectPath           Type        Reason      Message
--------- -------- ----- ---- ------------- -------- ------ -------
24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "gcr.io/google_containers/busybox"
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "gcr.io/google_containers/busybox"
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e

35秒后,再次查看Pod事件:

kubectl describe pod liveness-exec

在输出的底部,有一些消息表明活动探测失败,容器已被杀死并重新创建。

FirstSeen LastSeen    Count   From            SubobjectPath           Type        Reason      Message
--------- -------- ----- ---- ------------- -------- ------ -------
37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "gcr.io/google_containers/busybox"
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "gcr.io/google_containers/busybox"
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e
2s 2s 1 {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory

再等30秒,并确认容器已重新启动:

kubectl get pod liveness-exec

输出显示RESTARTS已增加:

NAME            READY     STATUS    RESTARTS   AGE
liveness-exec 1/1 Running 1 1m

定义一个活跃的HTTP请求

另一种活跃探测器使用HTTP GET请求。以下是基于gcr.io/google_containers/liveness 图像运行容器的Pod的配置文件。

apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-http
spec:
containers:
- name: liveness
image: gcr.io/google_containers/liveness
args:
- /server
livenessProbe:
httpGet:
path: /healthz
port:
httpHeaders:
- name: X-Custom-Header
value: Awesome
initialDelaySeconds:
periodSeconds:

大于等于200且小于400的任何代码表示成功。任何其他代码表示失败。在配置文件中,您可以看到Pod有一个容器。该periodSeconds字段指定kubelet应每3秒执行一次活动探测。该initialDelaySeconds字段告诉kubelet它应该在执行第一个探测之前等待3秒钟。要执行探测,kubelet向在容器中运行的服务器发送HTTP GET请求,并侦听端口8080.如果服务器/healthz路径的处理程序返回成功代码,则kubelet会将Container置于活动状态。如果处理程序返回失败代码,则kubelet会杀死Container并重新启动它。

您可以在server.go中看到服务器的源代码 。

在容器存在的前10秒中,/healthz处理程序返回200的状态。之后,处理程序返回500的状态。

http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
duration := time.Now().Sub(started)
if duration.Seconds() > 10 {
w.WriteHeader(500)
w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds())))
} else {
w.WriteHeader(200)
w.Write([]byte("ok"))
}
})

容器启动后3秒钟,kubelet开始执行运行状况检查。所以第一对健康检查将会成功。但10秒钟后,运行状况检查将失败,并且kubelet将会杀死并重新启动Container。

要尝试HTTP活动检查,请创建一个Pod:

kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/http-liveness.yaml

10秒钟后,查看Pod事件以验证活动探测失败,并重新启动Container:

kubectl describe pod liveness-http

定义TCP活动探测器

第三种活跃探测器使用TCP Socket。使用此配置,kubelet将尝试在指定端口上的容器上打开一个套接字。如果可以建立连接,容器被认为是健康的,如果它不能被认为是失败。

tcp-liveness-readiness.yaml
apiVersion: v1
kind: Pod
metadata:
name: goproxy
labels:
app: goproxy
spec:
containers:
- name: goproxy
image: gcr.io/google_containers/goproxy:0.1
ports:
- containerPort: 8080
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 20

如您所见,TCP检查的配置与HTTP检查非常相似。此示例使用准备和活动探测。容器启动后5秒钟,kubelet将发送第一个准备探测器。这将尝试连接到goproxy端口8080上的容器。如果探针成功,则将将标签准备好。kubelet将每10秒钟继续运行此检查。

除了准备探测器之外,该配置还包括活动探测器。容器启动15秒后,kubelet将运行第一个活动探测器。就像准备探测器一样,这将尝试连接到goproxy端口8080上的 容器。如果活动探测器失败,容器将重新启动。

使用命名端口

您可以使用命名的 ContainerPort 进行HTTP或TCP活动检查:

ports:
- name: liveness-port
containerPort: 8080
hostPort: 8080 livenessProbe:
httpGet:
path: /healthz
port: liveness-port

定义准备探测器

有时,应用程序暂时无法提供流量。例如,应用程序可能需要在启动期间加载大数据或配置文件。在这种情况下,您不想杀死应用程序,但您也不想发送请求。Kubernetes提供了准备探测器来检测和减轻这些情况。具有报告他们尚未准备好的容器的荚没有通过Kubernetes服务接收流量。

准备探测器的配置类似于活性探针。唯一的区别是您使用readinessProbe字段而不是livenessProbe字段。

readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5

HTTP和TCP准备探测器的配置也与活性探针保持一致。

准备和活力探针可以并行地用于同一个容器。使用两者可以确保流量未到达未准备好的容器,并且容器在失败时重新启动。

配置探头

探测器有许多领域可用于更准确地控制活动和准备度检查的行为:

  • initialDelaySeconds:开始活动探测之前容器启动后的秒数。
  • periodSeconds:执行探针的频率(以秒为单位)。默认为10秒。最小值为1。
  • timeoutSeconds:探针超时后的秒数。默认为1秒。最小值为1。
  • successThreshold:探针在失败后被认为是成功的最小连续成功。默认为1.对于活跃性,必须为1。最小值为1。
  • failureThreshold:当Pod启动并且探测失败时,Kubernetes将尝试failureThreshold放弃重新启动Pod之前的时间。默认为3.最小值为1。

HTTP探测器 具有可以设置的其他字段httpGet

  • host:要连接的主机名,默认为荚IP。您可能希望在httpHeaders中设置“主机”。
  • scheme:用于连接到主机的方案(HTTP或HTTPS)。默认为HTTP。
  • path:访问HTTP服务器的路径。
  • httpHeaders:在请求中设置的自定义标题。HTTP允许重复头。
  • port:容器上要访问的端口的名称或编号。数字必须在1到65535之间。

静态令牌文件

APIserver配置文件添加--token-auth-file=SOMEFILE 在命令行上给出选项时从文件读取承载令牌。目前,令牌无限期地持续下去,并且不重新启动API服务器就不能更改令牌列表。

令牌文件是一个至少有3列的csv文件:令牌,用户名,用户uid,后跟可选的组名。请注意,如果您有多个组,则该列必须用双引号括起来,例如

token,user,uid,"group1,group2,group3"
3754a2241da913441733649aa6d68571,kubelet-bootstrap,,"system:kubelet-bootstrap"

在请求中放置无记名标记

当使用来自http客户端的承载令牌认证时,API服务器需要Authorization一个值为的标头Bearer THETOKEN。不记名令牌必须是一个字符序列,只需使用HTTP的编码和引用功能就可以将其放入HTTP标头值中。例如:如果不记名令牌 31ada4fd-adec-460c-809a-9e56ceb75269出现在HTTP标头中,如下所示。

Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb7526

Bootstrap令牌

为了能够简化新群集的引导过程,Kubernetes包含一个名为Bootstrap令牌的动态管理的承载令牌类型。这些令牌作为秘密存储在kube-system命名空间中,在那里可以动态管理和创建它们。控制器管理器包含一个TokenCleaner控制器,用于在引导令牌过期时删除引导令牌。

代币是这种形式的[a-z0-9]{6}.[a-z0-9]{16}。第一个组件是一个令牌ID,第二个组件是令牌密钥。您在HTTP标头中指定标记,如下所示:

Authorization: Bearer 781292.db7bc3a58fc5f07e

您必须使用--experimental-bootstrap-token-authAPI服务器上的标志启用引导令牌认证器 。您必须通过--controllers控制器管理器上的标志启用TokenCleaner控制器。这是用类似的东西来完成的--controllers=*,tokencleaner。 kubeadm会为你做这个,如果你正在使用它来引导群集。

认证者认证为system:bootstrap:<Token ID>。它包含在system:bootstrappers组中。命名和组有意限制用户阻止过去使用这些令牌进行引导。用户名和组可以被使用(并被使用kubeadm)来制定适当的授权策略以支持引导群集


使用 kubeconfig 文件配置跨集群认证

Kubernetes 的认证方式对于不同的人来说可能有所不同。

  • 运行 kubelet 可能有一种认证方式(即证书)。
  • 用户可能有不同的认证方式(即令牌)。
  • 管理员可能具有他们为个人用户提供的证书列表。
  • 我们可能有多个集群,并希望在同一个地方将其全部定义——这样用户就能使用自己的证书并重用相同的全局配置。

所以为了能够让用户轻松地在多个集群之间切换,对于多个用户的情况下,我们将其定义在了一个 kubeconfig 文件中。

此文件包含一系列与昵称相关联的身份验证机制和集群连接信息。它还引入了一个(用户)认证信息元组和一个被称为上下文的与昵称相关联的集群连接信息的概念。

如果明确指定,则允许使用多个 kubeconfig 文件。在运行时,它们与命令行中指定的覆盖选项一起加载并合并(参见下面的 规则)。

k8s1.8 ingress 配置的更多相关文章

  1. [转帖]在 k8s 中通过 Ingress 配置域名访问

    在 k8s 中通过 Ingress 配置域名访问 https://juejin.im/post/5db8da4b6fb9a0204520b310 在上篇文章中我们已经使用 k8s 部署了第一个应用,此 ...

  2. kubernetes Traefik ingress配置详解

    理解Ingress 简单的说,ingress就是从kubernetes集群外访问集群的入口,将用户的URL请求转发到不同的service上.Ingress相当于nginx.apache等负载均衡方向代 ...

  3. Kubernetes 使用 ingress 配置 https 集群(十五)

    目录 一.背景 1.1 需求 1.2 Ingress 1.3 环境介绍 二.安装部署 2.1.创建后端 Pod 应用 2.2 创建后端 Pod Service 2.3.创建 ingress 资源 2. ...

  4. k8s nginx ingress配置TLS

    在没有配置任何nginx下,k8s的nginx默认只支持TLS1.2,不支持TLS1.0和TLS1.1 默认的 nginx-config(部分可能叫 nginx-configuration)的配置如下 ...

  5. Ingress介绍与安装配置

    在 Kubernetes 集群中,Ingress是授权入站连接到达集群服务的规则集合,为您提供七层负载均衡能力.您可以给 Ingress 配置提供外部可访问的 URL.负载均衡.SSL.基于名称的虚拟 ...

  6. 007.kubernets的headless service配置和ingress的简单配置

    前面配置了servcie的nodepoint和clusterIP附在均衡 一 headless service配置 1.1 默认下的DNS配置 [root@docker-server1 deploym ...

  7. 8.5 Ingress实现基于域名的多虚拟主机、URL转发、及多域名https实现等案例

    1.什么是Ingress Ingress 公开了从k8s集群外部到集群内服务的 HTTP 和 HTTPS 路由. 流量路由由 Ingress 资源上定义的规则控制. 可以将 Ingress 配置为服务 ...

  8. kubernetes系列09—Ingress控制器详解

    本文收录在容器技术学习系列文章总目录 1.认识Ingress 1.1 什么是Ingress? 通常情况下,service和pod仅可在集群内部网络中通过IP地址访问.所有到达边界路由器的流量或被丢弃或 ...

  9. Kubernetes Ingress管理

    目录 Ingress介绍 1.Pod漂移问题 2.端口管理问题 3.域名分配及动态更新问题 Nginx Ingress配置 1.部署默认后端 2.部署Ingress Controller 3.部署In ...

随机推荐

  1. Unix 高手的10个好习惯

    引言 当您经常使用某个系统时,往往会陷入某种固定的使用模式.有时,您没有养成以尽可能最好的方式做事的习惯.有时,您的不良习惯甚至会导致出现混乱.纠正此类缺点的最佳方法之一,就是有意识地采用抵制这些坏习 ...

  2. python数据类型之字典

    字典定义 字典是一种 key-value 的数据类型,这点很重要,是区别使用列表和字典的依据. 语法格式: info = { 'stu1101': "Aaron", 'stu110 ...

  3. 【 js 片段 】移动端适配简易步骤

    手机端全部适配简易步骤,不确保没有bug. 1.HTML 的 head 部分中加入如下代码: <meta name="viewport" content="widt ...

  4. 给model模型传数组参数

    $res = $this->Company->companyDischarge($this->user_id,array(0=>'c.limit_sum>0',1=> ...

  5. mysqli 查询

    $mysqli = new mysqli('localhost', 'user', 'pwd', 'dbname'); $query = "select goods_id,goods_nam ...

  6. PHP 抽象类实现接口注意事项(含PHP与.Net的区别)

    最近在学习Drupal8,看到源码里面一个抽象类BlockBase实现了一个接口BlockPluginInterface,但是并没有实现该接口的所有方法.然后我就不淡定了,因为之前是做.NET的,记忆 ...

  7. PHP isset()与empty()的使用区别

    PHP的isset()函数 一般用来检测变量是否设置 格式:bool isset ( mixed var [, mixed var [, ...]] ) 功能:检测变量是否设置 返回值: 若变量不存在 ...

  8. 为website安装免费的letsencrypt证书

    Certbot官网:https://certbot.eff.org 1. 安装certbot命令 wget https://dl.eff.org/certbot-auto chmod a+x cert ...

  9. mysql常用语句备忘

    1.连接本地数据库 mysql -h localhost -u root -p123 2.连接远程数据库 mysql -h 192.168.0.201 -P 3306 -u root -p123 3. ...

  10. C# 中 DataTable 使用详解。

    在项目中经常用到DataTable,如果DataTable使用得当,不仅能使程序简洁实用,而且能够提高性能,达到事半功倍的效果,现对DataTable的使用技巧进行一下总结. 一.DataTable简 ...