Summary of K8S using Helm to install RabbitMQ and Redis

foreword

I remember that in the first half of 2021 last year, I taught myself k8s and used helm to install rabbitmq and redis. It can be used in development, testing and production environments, but it will be useless after the second half of the year. When I picked it up again, I found that many knowledge points were forgotten. Now, this article is to summarize the personal summary of using helm to install rabbitmq and redis to share with you.

Summarize

1. Expose the service to external clients

first is exposed by service type:

Here are some types of services:

Clusterip : The default type, which automatically assigns a virtual IP that can only be accessed within the Cluster, and is generally used for load balancing within the cluster.

NodePort (service exposed to the outside) : Bind a mapped port to each machine for Service based on ClusterIP, and external network clients can access through NodeIP and Nodeport.

LoadBalancer (service exposed externally) : Based on NodePort, create an external load balancer with cloud provider and forward requests to NodeIP and NodePort

ExternalName : Introduce services from outside the cluster into the cluster and use them directly inside the cluster. No proxy of any kind is created, only kube-dns after 1.7 supports it.

So you can set the service to NodePort or LoadBalancer to expose the service externally

Second exposure via ingress:
In addition, externalIPs can also enable various services to provide external services, but when there are many cluster services, the biggest disadvantage of NodePort method is that it will occupy many ports of cluster machines; the biggest disadvantage of LB method is that one LB per service is a bit wasteful and expensive. It is troublesome and requires support other than k8s; while ingress only needs one NodePort or one LB to meet the external service needs of all services.

2. Rabbitmq or redis access methods are different in different environments

For example: Rabbitmq access is different in the development environment and the test environment. First of all, let’s talk about the test environment. Generally, our test environment will have a test server. We only need to put the rabbitmq and the foreground and background pods in the same cluster, so that we can pass k8s to access the cluster domain name, as follows:

test-redis-master.redis.svc.cluster.local
test-rabbitmq.rabbitmq.svc.cluster.local

How to get this domain name? It can be resolved by installing dnsutils:

kubectl run dnsutils --image=tutum/dnsutils --generator=run-pod/v1 --command -- sleep infinity

kubectl exec dnsutils -- nslookup test-rabbmit-headless.rabbitmq                                                                                                                     130 ↵
Server:        172.21.0.10
Address:    172.21.0.10#53

Name:    nacos-headless.default.svc.cluster.local
Address: 172.20.0.119

However, the development environment is different, because the code of the development environment is on our local machine, so you cannot use the above cluster domain name to access, then how to make the local machine access rabbitmq and redis services, the answer is in the above summary, We can expose rabbitmq and redis in the above three ways, which three? And which development environment should I choose?

1、NodePort
2、LoadBalancer
3、Ingress

Here I will only talk about the development environment. Since it is a development environment, we will use the minimum cost to complete the work. Our first choice is NodePort, because we use StatefulSet to deploy rabbitmq and redis, so obviously the IP is also fixed. Yes, we only need to access it through the node IP+PORT method. The node IP can be seen by observing the background management system of the pod or service third-party service provider. Of course, you can also view it through commands.

3. Helm delete service

You can operate it directly on the console of the third-party service provider. Note that it is also deleted together with the PVC.

4. What is Headless Services?

Sometimes load balancing is not needed or desired, and a separate Service IP. In this case, you can create a Headless Service by specifying the Cluster IP (spec.clusterIP) as "None".

Notice:

1. Pods under the same Service can communicate with each other directly according to PodIP
Pods under different services need to rely on cluster ip for pod communication between clusters
The IP address of the Service, which is the virtual IP address. The external network cannot be pinged, only the internal access of the kubernetes cluster is used.

2. dnsutils specifies the namespace query:

kubectl exec -i -t dnsutils -- nslookup <service-name>.<namespace>

3. After the Service type is set to NodePort in the development environment, the correct corresponding port and IP must be found, otherwise the access will fail, such as: accessing rabbitmq

NAME                             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                                                         AGE
service/test-rabbitmq            NodePort    172.21.10.248   <none>        5672:31469/TCP,4369:32745/TCP,25672:32057/TCP,15672:31961/TCP   183d
service/test-rabbitmq-headless   ClusterIP   None            <none>        4369/TCP,5672/TCP,25672/TCP,15672/TCP                           183d

Because the graphical interface of rabbitmq is the port corresponding to 15672, it should be: 31961.

NAME                          TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
service/test-redis-headless   ClusterIP   None           <none>        6379/TCP         5h58m
service/test-redis-master     NodePort    172.21.5.38    <none>        6379:30554/TCP   5h58m
service/test-redis-replicas   NodePort    172.21.9.204   <none>        6379:32709/TCP   5h58m

Similarly for Redis, the external port of 6379 should be: 30554. Of course redis has no graphical interface.

Remaining problem

After rabbitmq is exposed to the outside world through the ingress method, there is no problem in accessing the domain name in the cluster, but when accessing the UI graphical interface through the external real domain name, it has never been accessible, so I chose NodePort and LoadBalancer to expose it to the outside world. If anyone knows Can you tell me.

Quote:

k8s external service ingress