docker + k8s Basics five

Docker + K8s Basics (V)

 

---

 

• service resources Introduction
  
  • A: Operating Characteristics service resources
• service use
  • A: service field Introduction
  • B: Simple use of ClusterIP
  • C: Simple use of NodePort
  • D：LoadBalancer和ExternalName
  • E: Headless service

---

♣ a: service resource description

A: Operating Characteristics service resources:

kubernetes of service resources:
nodes throughout k8s cluster of pods resource is the smallest objects that provide a real service an important part, to access the endpoint when we need to be accessed by external factors, each pod resources is inconsistent we need to set a fixed endpoint access to provide access, the access endpoint is an intermediate layer under the supremacy and control pod, the middle layer called service, service will be strictly dependent on a key component called k8s coredns (new version) and kube-dns (old versions prior to version 1.11), so we will need to deploy coredes or kube-dns at the time of deployment.
kubernetes client in order to provide network functions, need to rely on third-party programs, such programs in the new version can be used to access any third-party programs follow this standard by cni (container network plug-in standard interface), for example, we use to the flannel.
kubernetes ip address three types:
. 1: network node
2: pod network
node address and the pod are real and arranged.
3: cluater (cluster address) or called the service address, the address is a virtual address (virtual ip), these addresses do not appear on the interface, just appear in regular service among.
Each node on the working kube-proxy component, the component will be real-time monitoring of changes in the information service resources, this embodiment monitors the request is implemented by an inherent kube-proxy by way of (Watch), once service resource changed, kube-proxy must convert it to above the current node can be on top of regular service schedule (this rule may be ipvs iptables rules or, depending on the implementation of service)
service implementation in there are three models on k8s:

　　　　　　　　
1: userspace (user space)
　　when the user's access service request will first reach the upper, by the service in the kube-proxy converts user space on a listening socket, the next process is completed sub kube-proxy to service agent over the pod to the service associated with each, to achieve scheduling.

　　This model is not efficient, because the user service request is to be transferred into the work through the work on each of the core above the "Host" user space kube-proxy, kube-proxy encapsulates the kernel space to the request packets service resources, service is scheduled to rule on each pod resources.

　　　　　　　　
2: iptabeles:
　  the current user of the IP service request directly to the request, the request will be taken at the local service work in kernel space, and then to dispatch directly associated pod, and the entire scheduling is done based iptables rules.

　　　　　　　　
3: ipvs:
      and iptables same, but the rules replaced ipvs rules.
When configuring k8s set k8s work under any mode, the rule will generate a corresponding mode, the default before the 1.1 userspace, 1.11 ipvs use the default, if ipvs not activated, it will be downgraded to iptables.
When the pods resource cluster has changed, this information will immediately react to the above apiservice, because this change will be stored directly in apiservice of ectd them, this change will immediately trigger kube-proxy will be sent to service its resources or converted to iptables rules ipvs, these conversions are dynamically and in real time.

♣ two: service use:

A: service field description:

[root@www kubeadm]# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   77m
在我们初始化集群的时候已然帮忙创建了一个名称叫kubernetes的service资源，这个资源很重要，是保证我们service和集群节点之间联系的，而且10.96.0.1是面向集群内部的地址。
[root@www kubeadm]# kubectl explain svc  也是包含5个一级字段
KIND:     Service
VERSION:  v1

DESCRIPTION:
     Service is a named abstraction of software service (for example, mysql)
     consisting of local port (for example 3306) that the proxy listens on, and
     the selector that determines which pods will answer requests sent through
     the proxy.

FIELDS:
   apiVersion   <string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/api-conventions.md#resources

   kind <string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds

   metadata     <Object>
     Standard object's metadata. More info:
     https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata

   spec <Object>
     Spec defines the behavior of a service.
     https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status

   status       <Object>
     Most recently observed status of the service. Populated by the system.
     Read-only. More info:
     https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status

[root@www kubeadm]# kubectl explain svc.spec.ports（ports是用于把那个端口和后端的容器端口建立关联关系）
KIND:     Service
VERSION:  v1

RESOURCE: ports <[]Object>

DESCRIPTION:
     The list of ports that are exposed by this service. More info:
     https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

     ServicePort contains information on service's port.

FIELDS:
   name <string>
     The name of this port within the service. This must be a DNS_LABEL. All
     ports within a ServiceSpec must have unique names. This maps to the 'Name'
     field in EndpointPort objects. Optional if only one ServicePort is defined
     on this service.

   nodePort     <integer>
     The port on each node on which this service is exposed when type=NodePort
     or LoadBalancer. Usually assigned by the system. If specified, it will be
     allocated to the service if unused or else creation of the service will
     fail. Default is to auto-allocate a port if the ServiceType of this Service
     requires one. More info:
     https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport

   port <integer> -required-  service的端口
     The port that will be exposed by this service.

   protocol     <string>   node端口    
     The IP protocol for this port. Supports "TCP", "UDP", and "SCTP". Default
     is TCP.
 
   targetPort   <string>   pods端口
     Number or name of the port to access on the pods targeted by the service.
     Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. If
     this is a string, it will be looked up as a named port in the target Pod's
     container ports. If this is not specified, the value of the 'port' field is
     used (an identity map). This field is ignored for services with
     clusterIP=None, and should be omitted or set equal to the 'port' field.
     More info:
     https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service

[root@www kubeadm]# kubectl explain svc.spec.selector （我们需要关联到哪些pods资源上）
KIND:     Service
VERSION:  v1

FIELD:    selector <map[string]string>

DESCRIPTION:
     Route service traffic to pods with label keys and values matching this
     selector. If empty or not present, the service is assumed to have an
     external process managing its endpoints, which Kubernetes will not modify.
     Only applies to types ClusterIP, NodePort, and LoadBalancer. Ignored if
     type is ExternalName. More info:
     https://kubernetes.io/docs/concepts/services-networking/service/


spec.clusterIP（指定固定的ip，创建之后无法改变）

[root@www kubeadm]# kubectl explain svc.spec.type  （service的类型）
KIND:     Service
VERSION:  v1

FIELD:    type <string>

DESCRIPTION:
     type determines how the Service is exposed. Defaults to ClusterIP. Valid
     options are ExternalName, ClusterIP, NodePort, and LoadBalancer.
     "ExternalName" maps to the specified externalName. "ClusterIP" allocates a
     cluster-internal IP address for load-balancing to endpoints. Endpoints are
     determined by the selector or if that is not specified, by manual
     construction of an Endpoints object. If clusterIP is "None", no virtual IP
     is allocated and the endpoints are published as a set of endpoints rather
     than a stable IP. "NodePort" builds on ClusterIP and allocates a port on
     every node which routes to the clusterIP. "LoadBalancer" builds on NodePort
     and creates an external load-balancer (if supported in the current cloud)
     which routes to the clusterIP. More info:
     https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types

service资源的字段介绍

svc.spec.type字段类型：

类型一共分为4种：
1：ExternalName（把集群外部的服务引入到集群内部直接使用）；

2：ClusterIP；

3：NodePort（接入外部）；

4：LoadBalancer（支持lbaas负载均衡的一键调度）

B：ClusterIP的简单使用：

[root@www TestYaml]# cat redis-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: redis
  namespace: default
spec:
  selector:
    app: redis
  clusterIP: 10.98.98.98  （指定ip创建的时候需要注意网段和地址冲突问题）
  type: ClusterIP
  ports:
  - port: 6379  
    targetPort: 6379
[root@www TestYaml]# kubectl apply -f redis-svc.yaml
service/redis created
[root@www TestYaml]# kubectl get svc
NAME         TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
kubernetes   ClusterIP   10.96.0.1     <none>        443/TCP    102m
redis        ClusterIP   10.98.98.98   <none>        6379/TCP   14s  可以看到redis的ip和端口是配置文件指定的ip和端口
[root@www TestYaml]# kubectl describe svc redis
Name:              redis
Namespace:         default
Labels:            <none>
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"redis","namespace":"default"},"spec":{"clusterIP":"10.98.98.98","...
Selector:          app=redis
Type:              ClusterIP
IP:                10.98.98.98
Port:              <unset>  6379/TCP  指定的service端口
TargetPort:        6379/TCP   指定的pod端口
Endpoints:         <none>
Session Affinity:  None
Events:            <none>
这里需要说明的是service不会直接到pod，而是需要进过中间层Endpoints的，Endpoints也是k8s上标准的对象，再由Endpoints关联至pods资源上。

ClusterIP案例

C：NodePort的简单使用：

[root@www TestYaml]# cat NodePort.svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: default
spec:
  selector:
    app: myapp
  clusterIP: 10.99.99.99
  type: NodePort
  ports:
  - port: 8088
    targetPort: 8088
    nodePort: 30008  从30000到32767之间的都可以，默认是动态分配的
[root@www TestYaml]# kubectl apply -f NodePort.svc.yaml
service/myapp created
[root@www TestYaml]# kubectl get svc
NAME         TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
kubernetes   ClusterIP   10.96.0.1     <none>        443/TCP          125m
myapp        NodePort    10.99.99.99   <none>        8088:30008/TCP   22s  service的8088端口映射成node上的30008
redis        ClusterIP   10.98.98.98   <none>        6379/TCP         23m
通过此种方式创建的pod就可以在外部直接访问了，只不过要进过好几级转换，先是port，再是protocol，在转换到targetPort上。

NodePort案例

D：LoadBalancer和ExternalName：

　　　　　　　　

如果购买了阿里云平台的环境虚拟机（带ibaas负载均衡服务），你在上面搭建了一共k8s的集群服务，k8s会自动去调用云平台的ibaas服务，用软件的方式去把用户的访问请求负载调度至后端的任意一个node节点上，在由节点上的service服务再负载调度至后端的任意一个pod之上，整个过程都是自动的，而且是两级负载均衡调度。

ExternalName：

我们在构建pods的时候本来就是层级关系的，例如db被tomcat访问，tomcat被nginx访问，这种被访问的形式本身就是一种client的存在，那如果是我们的nginx服务在集群外部的某台集群上，想nginx能访问到集群内部的tomcat就需要使用ExternalName，在创建yaml文件的时候ExternalName是一个真实有效且能被dns所解析的服务名，然后用户的访问请求走外部的nginx，nginx在发送请求报文给集群内部的nodeIP到service，有service调度到后端的pod（tomcat），pod在返回给service，最后返回到nginx上，实现访问，但是此种方式用的不多。

[root@www kubeadm]# kubectl explain svc.spec.externalName （externalName只能是类型为ExternalName的时候才有效）
KIND:     Service
VERSION:  v1

FIELD:    externalName <string>

DESCRIPTION:
     externalName is the external reference that kubedns or equivalent will
     return as a CNAME record for this service. No proxying will be involved.
     Must be a valid RFC-1123 hostname (https://tools.ietf.org/html/rfc1123) and
     requires Type to be ExternalName.
[root@www kubeadm]#

externalName字段说明

[root@www kubeadm]# kubectl explain svc.spec.sessionAffinity（svc还支持sessionAffinity）
KIND:     Service
VERSION:  v1

FIELD:    sessionAffinity <string>

DESCRIPTION:
     Supports "ClientIP" and "None". Used to maintain session affinity. Enable
     client IP based session affinity. Must be ClientIP or None. Defaults to
     None. More info:
     https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies
     这里的session支持两种，一个是ClientIP，将来自同一个ip访问的请求始终调度到同一个pod上。
     None就是默认的随机调度。

sessionAffinity字段说明

E：无头service：

无头service，即值创建service的时候不指定clusterIP，此时用户的访问请求不再是访问clusterIP而是转而访问pod上的ip

[root@www TestYaml]# kubectl explain svc.spec.clusterIP
KIND:     Service
VERSION:  v1

FIELD:    clusterIP <string>

DESCRIPTION:
     clusterIP is the IP address of the service and is usually assigned randomly
     by the master. If an address is specified manually and is not in use by
     others, it will be allocated to the service; otherwise, creation of the
     service will fail. This field can not be changed through updates. Valid
     values are "None", empty string (""), or a valid IP address. "None" can be
     specified for headless services when proxying is not required. Only applies
     to types ClusterIP, NodePort, and LoadBalancer. Ignored if type is
     ExternalName. More info:
     https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies
     在指定clusterIP的时候可以指定为none（格式是""即可）
案例：
[root@www TestYaml]# cat NodePort.svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: default
spec:
  selector:
    app: myapp
  clusterIP: None  不指定ip
  ports:
  - port: 8088
    targetPort: 8088
[root@www TestYaml]# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP    81m
myapp        ClusterIP   None         <none>        8088/TCP   9s  可以看到ip是none标记
[root@www TestYaml]# kubectl get svc -n kube-system
NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE
kube-dns   ClusterIP   10.96.0.10   <none>        53/UDP,53/TCP,9153/TCP   83m   我们直接去解析coredns的ip就能直接看到pod ip的解析记录
[root@www TestYaml]# dig -t A myapp.default.svc.cluster.local. @10.96.0.10  我们直接解析coredns的ip看看下解析记录

; <<>> DiG 9.9.4-RedHat-9.9.4-74.el7_6.1 <<>> -t A myapp.default.svc.cluster.local. @10.96.0.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60422
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;myapp.default.svc.cluster.local. IN    A

;; ANSWER SECTION:
myapp.default.svc.cluster.local. 5 IN   A       10.244.2.9   可以看到这里有三个记录，ip分别是2.9,2.8,1.8
myapp.default.svc.cluster.local. 5 IN   A       10.244.2.8
myapp.default.svc.cluster.local. 5 IN   A       10.244.1.8

;; Query time: 0 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: 日 7月 14 11:29:23 CST 2019
;; MSG SIZE  rcvd: 201

[root@www TestYaml]# kubectl get pods -o wide
NAME                    READY   STATUS    RESTARTS   AGE    IP           NODE                       NOMINATED NODE   READINESS GATES
myapp-9758dcb6b-hl957   1/1     Running   0          4m6s   10.244.2.8   www.kubernetes.node1.com   <none>           <none>
myapp-9758dcb6b-z8rk6   1/1     Running   0          4m6s   10.244.2.9   www.kubernetes.node1.com   <none>           <none>
myapp-9758dcb6b-zl5jt   1/1     Running   0          4m6s   10.244.1.8   www.kubernetes.node2.com   <none>           <none>
上面的2.9,2.8,1.8对应的ip就是pod的ip，这样我们得出的结论就是当service没有clusterip的时候就会通过coredns来解析并转发到后端的pod之上。

无头service案例

service很好用，但是也是存在缺陷的，当面我们创建了service的时候，用户访问需要进行两级转换，如果是阿里云的lbaas则是两级调度，其实我们看到的是两级转换，但是落到ipvs或者iptebles之上就是四层调度。因为ipvs和iptables都是四层的，如果我们建立的是https服务的话，例如https对应的名称是myapp，那么你的每一个myapp都要配置成htpps的主机，因为ipvs或者iptables自身是无法卸载https会话的。
kubernetes还有一种引入外部流量的方式，叫ingress（是一种7层调度器）将外部的流量引入到内部来，但是也是无法脱离service的工作，必需要用pod7层功能的应用来调度，起能提供的应用有nginx，haprxoy等。在kubernetes之上应用比较多的是nginx，当然还有别的应用有各自相应的优势。