k8s services

services提供一个入口，通过一个ip和port能够访问到一个service后面的一组pods（提供同一个service），且能负载均衡。这样pods可以随时变换，而不需要随时更改ip和port。

 

 

service是通过同样的label来分组pods的，创建好RC后变可以通过kubectl expose来创建相对应的servcie

 

Using kubectl exec to test out a connection to the service by running curl in one of the pods

 

支持提供多个port（比如一个用于http一个用于https）。

clusterIp只能用于在cluster内部访问。

service's cluster IP is a virtual ip,only has meaning when combined with the service port.

discovering services through dns

client pods 可以通过域名fully qualified domain name(FQDN)来直接访问服务。

以上都是让pods在cluster内部访问

 

expose certain servcie to the outside

 

 

可以开放一个NodePortService来让外部访问，

可以设置sercieType为loadBalancer，然后设置一个loadBlancer's ip

创建一个ingress resource 可以expose multiple sercies through a single ip address

 

nodeport service不仅可以通过service的内部cluster IP访问，还可以通过任意node的IP和保留的node port来访问

使用如下：

$ kubectl get svc kubia-nodeport
NAME             CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
kubia-nodeport   10.111.254.223   <nodes>       80:30123/TCP   2m

• 10.11.254.223:80
• <1st node's IP>:30123
• <2nd node's IP>:30123, and so on.
• 

 

external  load  balancer

load balancer service有他自己的IP并分发所有请求。

apiVersion: v1
kind: Service
metadata:
  name: kubia-loadbalancer
spec:
  type: LoadBalancer                1
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: kubia

$ kubectl get svc kubia-loadbalancer
NAME                 CLUSTER-IP       EXTERNAL-IP      PORT(S)         AGE
kubia-loadbalancer   10.111.241.153   130.211.53.173   80:32143/TCP    1m

 

 

Ingress resource

loadBalancer需要一个自己的ip address，而ingress 只需要一个来为a dozens of services提供入口。

需要在cluster上运行一个ingress controller，下面是一个ingress resource definition

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kubia
spec:
  rules:
  - host: kubia.example.com               1
    http:
      paths:
      - path: /                           2
        backend:
          serviceName: kubia-nodeport     2
          servicePort: 80                 2

readiness probes 用于探测哪些pods是ready的便可以redirect请求到这些pod上。同样有三种

• An Exec probe, where a process is executed. The container’s status is determined by the process’ exit status code.
• An HTTP GET probe, which sends an HTTP GET request to the container and the HTTP status code of the response determines whether the container is ready or not.
• A TCP Socket probe, which opens a TCP connection to a specified port of the container. If the connection is established, the container is considered ready.

Unlike liveness probes, if a container fails the readiness check, it won’t be killed or restarted

 

USING A HEADLESS SERVICE FOR DISCOVERING INDIVIDUAL PODS？？？