k8s1.8 ingress 配置
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: 80 [root@k8s1 ingress]# vim ingress_443.yaml apiVersion: extensions/v1beta1 kind: Ingress metadata: name: nginx-default-443 namespace: default spec: tls: - hosts: - nginx.cinyi.com secretName: ingress-secret rules: - host: nginx.cinyi.com http: paths: - backend: serviceName: nginx-default servicePort: 80 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-80 namespace: fengjian spec: rules: - host: feng.cinyi.com http: paths: - backend: serviceName: my-nginx-fengjian servicePort: 80 [root@k8s1 ingress]# vim ingress-fengjian-443.yaml apiVersion: extensions/v1beta1 kind: Ingress metadata: name: nginx-fengjian-443 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 30; rm -rf /tmp/healthy; sleep 600 livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5
当容器启动时，它将执行此命令：在配置文件中，您可以看到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: 8080 httpHeaders: - name: X-Custom-Header value: Awesome initialDelaySeconds: 3 periodSeconds: 3
大于等于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  |
|---|
|
如您所见，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,10001,"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 文件。在运行时，它们与命令行中指定的覆盖选项一起加载并合并（参见下面的 规则）。
