We have deployed Apache ignite 2.14 in Kubernetes using GridGain's Operator.
The Operator is creating the service of type "LoadBalancer", when we try to change the type as "ClusterIP" operator is change it back to "LoadBalancer". We are trying to use this in production, so we cannot expose public IP. We need service of type "ClusterIP"
Is there any way to tell the operator to create the service as "ClusterIP" instead of "LoadBalancer" ?
Also is there any way to pass the tolerations & affinity information to operator, so that operator will create the ignite cluster based on that affinity ?
As per this config, there is not a setting which could direct the operator to use anything except a LoadBalancer.
You can however, adjust the settings on your cloud provider to make the IP not be visible to the outside world.
Related
I'm looking into altering the architecture of a hosting service intended to scale arbitrarily.
On a given machine, the service works roughly as follows:
Start a container running Redis cluster client that joins a global cluster.
Start containers for each of the "Models" to be hosted.
Use upstream Redis cluster for managing model global state. Handle namespacing via keys themselves.
I'm wondering if it might be possible to change to something like this:
For each Model, start a container running the Model and a Redis cluster client.
Reverse proxy the Redis service using something like Nginx to be available on a certain path, e.g., <host_ip>:6397/redis-<model_name>. (Note: I can't just proxy from different ports, because in theory this is supposed to be able to scale past 65,535 models running globally.)
Join the Redis cluster by using said path.
Internalizing the Redis service to the container is an appealing idea to me because it is closer to what the hosting service is supposed to achieve. We do want to share compute; we don't want to share a KV store.
Anyways, I haven't seen anything that suggests this is possible. So, sticking with the upstream may be my only option. But, in case anyone knows otherwise, I wanted to check and see.
I've got an express service running in a minikube cluster and I'm trying to set up a Redis client, but when I try run the service with the Redis client created it basically stalls on deployment and times out. As soon as I add the line:
const client = redis.createClient('http://127.0.0.1:6379');
My service will not deploy and run (even running the default with no supplied address causes the same issue).
I'm quite new to Kubernetes in general so I'm not sure if this is potentially an issue with minikube? Like trying to create a client from inside the cluster with that address isn't possible or something along those lines..
I'm completely lost with why just trying to create a client is causing this issue so any advice or direction would be greatly appreciated.
Try using "service-name.namespace-name.svc.cluster.local" instead of IP address to connect to service.
For example: If my service name is car-redis-service and namespace is default then the command goes like
redis.createClient(REDISPORT, redis://car-redis-service.default.svc.cluster.local)
Or
redis.createClient(REDISPORT,car-redis-service.default.svc.cluster.local)
(source)
Here REDISPORT is the port where redis is configured.
For more information on redis in kubernetes refer to this article.
I am wondering if it's possible to start an Apache Ignite client Node by passing configuration parameters to the JVM. For instance, we may start a server Node by running "org.apache.ignite.startup.cmdline.CommandLineStartup" and passing config parameters to it.
I know it's possible to start a Node from inside a class implementation by initializing Ignite interface and explicitly joining a Cluster.
The easiest way to start a client node is invoke the Ignition.start(..) method. For more details you can refer to any example shipped with Ignite and to this documentation page: https://apacheignite.readme.io/docs/clients-vs-servers
I am using Infinispan in distributed mode with number of owners = 2 and cluster of 8 JBoss servers.
For example: I have the key "1" and I put that in Infinispan cache. I want to get details (IP address) of those servers which are holding that key.
If you're using Infinispan in remote client-server mode and accessing it via Memcached or REST protocols, you can't - these protocols are key location agnostic.
With HotRod protocol, the client knows this location but it's not publicly exposed. For debugging purposes, you can obtain the TransportFactory from RemoteCacheManager via reflection, then ConsistentHash instance from TransportFactory and run .getServer(byte[]) method.
Certainly, such reflection is certainly not recommended for production. Why do you need the key's location?
The TcpTransportFactory class has a log on trace level that says the server used by that key.
So, for instance, if you change your Log4j XML config to something like:
<Logger name="org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory" level="TRACE"/>
You will get:
19:32:32,253 TRACE [HotRod-client-async-pool-34] [TcpTransportFactory] Using consistent hash for determining the server: /10.123.456.1:11222
I would like a recommendation/idea on a method to configure properties for a running Mule service dynamically, i.e. I want the service to pick up the new settings without the need to restart Mule. Typically the kind of properties/settings I would like to change are FTP connector user ID, passwords, service URLs etc.
Any idea would be welcome.
Regards, Ola
Use the URI endpoint format do dynamically address endpoints. In simple cases you may be able to use the message properties in a TemplateEndpointRouter
Otherwise You need to write a component that composes the URI and sends the message to the dynamic endpoint using the MuleEventContext or MuleClient.
See here:
http://www.mulesoft.org/documentation/display/MULE2USER/Outbound+Routers#OutboundRouters-TemplateEndpointRouter
http://www.mulesoft.org/documentation/display/MULE2USER/Using+the+Mule+Client#UsingtheMuleClient-PerforminganEventRequestCall
http://www.mulesoft.org/documentation/display/MULE2USER/Mule+Endpoint+URIs
Mule exposes all service configuration via JMX, but I don't see any obvious way to reconfigure the connectors without a restart. They are internally managing pools of connections.
If there is a limited, you can create connectors for each and reconfigure the routes via jmx attributes.
If it is to be fully dynamic you likely need to implement your own service component to manage the ftp connection. Exposing the connection management, configuration, and restarting via JMX should be pretty straight forward.