Shulou(Shulou.com)06/02 Report--

There are two ways to discover services within a k8s cluster:

1. Discover through variables

You can only get variables in the same namespace

Variables are acquired in order, and referenced variables must be created first.

2. Discover through DNS

There is dns in kube-system, which can automatically discover the clusterIP of services in all namespaces.

Therefore, when one service accesses another service in the same namespace, it can be accessed directly through the service name.

Whenever a service is created (no matter which ns it is created in), it will automatically register with the DNS in the kube-system

If it is a different namespace, you can use the service name. Namespace name to access the

Service is an abstract object that defines a set of logical collections of Pod and a policy for accessing them.

Service mainly implements intra-cluster communication, as well as internal and external communication based on four layers (such as ports).

Service is used to provide pod with a fixed and unified access interface and load balancing capability, and with the help of the service discovery function of the new generation of DNS, it solves the problem of client discovering and accessing containerized applications.

The address of the service does not change, it is associated with the back-end pod through the tag selector.

Three kinds of ip in k8s cluster:

1. The IP address of the Node IP:Node node

2. Pod IP: the IP address of Pod

3. Cluster IP: the IP address of Service, which cannot be connected with ping.

Service types in k8s cluster

$kubectl explain svc.spec.type

Defaults to ClusterIP. Valid options are ExternalName, ClusterIP, NodePort, and LoadBalancer.

If you do not use the type field, the default is ClusterIP.

1. ClusterIP: expose the service through the internal IP of the cluster. Select this value, and the service can only be accessed within the cluster. This is also the default ServiceType.

K8s cluster internal traffic trend:

Internal client-service (ClussterIp:Port)-endpoint (ip and port list)-Application pod (port)

2. NodePort: expose services through IP and static ports (NodePort) on each Node node. The NodePort service is routed to the ClusterIP service, and the ClusterIP service is created automatically. A NodePort service can be accessed from outside the cluster by request.

Service data flow of type NodePort:

External user-external LB--nodePort (cluster portal)-service--endpoint-- application pod

3. Service applications of LoadBalancer type in public cloud environment

4. Service of ExternalName type is used to enable pod inside the cluster to access services outside the cluster.

Data flow: internal pod--service-- external services

This type of service has no serviceIP, no nodeport, no tag selector, and requires CNAME parsing records

It is the kube-proxy of each working node that completes the internal traffic forwarding.

There are three modes of proxy operation:

1. Userspace agent mode

2. Iptables agent mode

3. Ipvs agent mode

The only difference between ipvs mode and iptables mode is that the scheduling function of request traffic is performed by ipvs, while other functions are still performed by iptables.

There are two ways to create a service:

1. Use the kubectl expose command

2. Define the resource inventory file

$kubectl explain svc.metadata

FIELDS:

Labels

Name of name # svc

Namespace

$kubectl explain svc.spec

FIELDS:

Ip address of clusterIP # svc

Ports

Selector

Type

$kubectl explain svc.spec.clusterIP

ClusterIP is the IP address of the service and is usually assigned randomly by the master.

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.

ClusterIP represents the ip address of svc, which is usually obtained automatically and does not need to be specified manually. If you do not use this field or specify an empty value, the ip address is obtained automatically.

If you specify a value of None, the svc is headless.

This field cannot be used when the type of svc is ExternalName.

$kubectl explain svc.spec.ports

FIELDS:

1 、 port:

Refers to the port exposed by the service. It is a required option when creating a svc with a yaml file. It can be unspecified when created with the command. If not specified, it will inherit the containerPort in the pod.

2 、 nodePort:

Refers to the node node port (this parameter is required only when type is NodePort or LoadBalancer, which is usually automatically generated) for external communication.

3 、 targetPort:

Refers to the port exposed by the backend pod, which is the containerPort in pod.

If you specify neither port nor targetPort, then both port and targetPort inherit the containerPort in pod.

If port is specified and targetPort is not specified, targetPort inherits the port value, so you must specify the target Port value as containerPort in pod, and you cannot specify the port number casually, unless the port value is the same as the containerPort in pod (in this case targetPort may not be specified).

When type is ClusterIP, the port through which traffic passes is:

Svc Port (port)-pod Port (targetPort)-Container Port (containerPort)

When type is NodePort, the port through which traffic passes is:

Node Port (NodePort)-svc Port (port)-pod Port (targetPort)-Container Port (containerPort)

Use the command to create a svc (containerPort is 8080)

$kubectl get deploy

$kubectl expose deploy deploy_name1

$kubectl get svc

$kubectl delete svc svc_name

$kubectl expose deploy deploy_name2-port=8080

$kubectl expose deploy deploy_name3--port=80-target-port=8080

$kubectl expose deploy deploy_name4-port=80-target-port=8080-type=NodePort

$kubectl get svc svc_name-o yaml

Spec: clusterIP: 10.97.153.130 externalTrafficPolicy: Cluster ports:-nodePort: 30693 port: 80 protocol: TCP targetPort: 8080

$curl http://10.97.153.130

$curl http://192.168.1.243:30693 # 243is the master address

$kubectl delete svc svc_name

Create svc with yaml file

ApiVersion: v1kind: Servicemetadata: labels: ame: mysvc name: mysvcspec: ports:-port: 80 targetPort: 8080 selector: app: mysvc # matches the backend pod type: NodePort labeled app: mysvc

Service of Headless headless type:

The service has no IP, and the client does not go through the service, but directly accesses the backend pod

The type for headless service cannot be NodePort.

Kind: Servicespec: clusterIP: None # (this parameter can be set to None to become headless service)

Check what pod are available under a service:

$kubectl get svc

$kubectl get svc svc_name-o yaml

$kubectl describe svc svc_name

Selector: run=nginx1

$kubectl get pod-l run=nginx1

Verify that services are discovered through DNS

$kubectl get pod-n kube-system | grep dns

Kube-dns ClusterIP 10.96.0.10 53/UDP,53/TCP

$yum install bind-utils-y

$dig-t A svc_name.default.svc.cluster.local. @ 10.96.0.10

$kubectl get svc svc_name-o yaml

Verify dns service discovery in pod

$kubectl run busybox-rm-it-image=busybox sh

/ # cat / etc/resolv.conf

Nameserver 10.96.0.10

Search default.svc.cluster.local svc.cluster.local cluster.local example.com

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.