Looks like it works when I exclude the --subjectAlternativeNames parameter, whereas it fails with the null error when I specify this parameter. For example, this works: /opt/nifi/nifi-toolkit-current/bin/tls-toolkit.sh client -c nifi-ca-cs -t a5s4d545h48s6d87fa6sd7g45f6g4fga84sd6a8e7f6ga786a --dn "CN=$(hostname -f),OU=NIFI"
But this doesn't: /opt/nifi/nifi-toolkit-current/bin/tls-toolkit.sh client -c nifi-ca-cs -t a5s4d545h48s6d87fa6sd7g45f6g4fga84sd6a8e7f6ga786a --dn "CN=$(hostname -f),OU=NIFI" --subjectAlternativeNames "<my proxy server's hostname>" I'll dig further to see if there is any way I can get the SAN to work. On Mon, Dec 30, 2019 at 4:51 PM Joe Gresock <[email protected]> wrote: > Thanks for the suggestion, apparently there was a typo on my nifi-ca-cs > service that caused the pod not to be matched. Unfortunately, even once I > corrected this, I'm still getting the "Service client error: null". > > I'll keep working on it. Thanks for your help! > > On Sat, Dec 28, 2019 at 5:53 AM Swarup Karavadi <[email protected]> wrote: > >> Hey Joe, >> >> I'm glad that the article was of some help. I, unfortunately, do not >> recollect running into that specific error scenario. At the risk of stating >> the obvious, can you check if the nifi-ca-cs service is reachable from your >> nifi pod? >> >> On the CRD bit, we are considering going this route with NiFi stateless. >> We are experimenting to see if we can have something like "NiFi K" that can >> be inline with the way "Camel K" works. Based on our current (limited) >> understanding of NiFi stateless, we think the CRD approach will help scale >> NiFi stateless horizontally with much more ease. >> >> Cheers, >> Swarup. >> >> On Sat, Dec 28, 2019 at 4:32 AM Mike Thomsen <[email protected]> >> wrote: >> >>> If you don't see a value when you run "echo %JAVA_HOME%" then you need >>> to check to see if it was set globally in Windows, and if it was, you need >>> to open a new command shell. >>> >>> On Mon, Oct 21, 2019 at 12:37 PM <[email protected]> wrote: >>> >>>> Any suggestions? >>>> >>>> >>>> >>>> I downloaded NiFi, but when I run the runnifi from the bin folder >>>> nothing happens. I get the following message. The JAVA_HOME environment >>>> variable is not defined correctly. I downloaded the latest JRE, but still >>>> get the same error message. >>>> >>>> >>>> >>>> >>>> >>>> *From:* Swarup Karavadi <[email protected]> >>>> *Sent:* Monday, October 21, 2019 12:19 PM >>>> *To:* [email protected] >>>> *Cc:* [email protected] >>>> *Subject:* Re: NiFi Kubernetes question >>>> >>>> >>>> >>>> If you are hosting on the cloud, I'd recommend going for dedicated >>>> worker nodes for the NiFi cluster. There might be rare (or not) occasions >>>> when a worker node is under high load and needs to evict pods. If your NiFi >>>> deployment's pod disruption budget allows for eviction of pods then there >>>> are always chances that an evicted NiFi pod can be rescheduled on a >>>> different node that is tainted (tainted because the node may not meet the >>>> pod's volume affinity requirements). Your best case scenario when this >>>> happens is that the pod will keep getting rescheduled on different nodes >>>> until it starts up again. The worst case scenario is that it'll be stuck in >>>> a CrashLoopBackoff limbo. >>>> >>>> >>>> >>>> Disclaimer - I speak from my experience on a non production >>>> environment. Our NiFi clusters will be deployed to a production k8s >>>> environment in a few weeks from now. I am only sharing some learnings I've >>>> had w.r.t. k8s statefulsets along the way. >>>> >>>> >>>> >>>> Hope this helps, >>>> >>>> Swarup. >>>> >>>> >>>> >>>> On Mon, Oct 21, 2019, 9:32 PM Wyllys Ingersoll < >>>> [email protected]> wrote: >>>> >>>> >>>> >>>> We had success running a 3-node cluster in kubernetes using modified >>>> configuration scripts from the AlexJones github repo - >>>> https://github.com/AlexsJones/nifi >>>> >>>> Ours is on an internal bare-metal k8s lab configuration, not in a >>>> public cloud at this time, but the basics are the same either way. >>>> >>>> >>>> >>>> - setup nifi as a stateful set so you can scale up or down as needed. >>>> When a pod fails, k8s will spawn another to take its place and zookeeper >>>> will manage the election of the master during transitions. >>>> >>>> - manage your certs as K8S secrets. >>>> >>>> - you also need to also have a stateful set of zookeeper pods for >>>> managing the nifi servers. >>>> >>>> - use persistent volume mounts to hold the flowfile, database, content, >>>> and provenance _repository directories >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Oct 21, 2019 at 11:21 AM Joe Gresock <[email protected]> >>>> wrote: >>>> >>>> Apologies if this has been answered on the list already.. >>>> >>>> >>>> >>>> Does anyone have knowledge of the latest in the realm of nifi >>>> kubernetes support? I see some pages like >>>> https://hub.helm.sh/charts/cetic/nifi, and >>>> https://github.com/AlexsJones/nifi but am unsure which example to pick >>>> to start with. >>>> >>>> >>>> >>>> I'm curious how well kubernetes maintains the nifi cluster state with >>>> pod failures. I.e., do any of the k8s implementations play well with the >>>> nifi cluster list so that we don't have dangling downed nodes in the >>>> cluster? Also, I'm wondering how certs are managed in a secured cluster. >>>> >>>> >>>> >>>> Appreciate any nudge in the right direction, >>>> >>>> Joe >>>> >>>> >>>> >>>> On Mon, Oct 21, 2019, 9:32 PM Wyllys Ingersoll < >>>> [email protected]> wrote: >>>> >>>> >>>> >>>> We had success running a 3-node cluster in kubernetes using modified >>>> configuration scripts from the AlexJones github repo - >>>> https://github.com/AlexsJones/nifi >>>> >>>> Ours is on an internal bare-metal k8s lab configuration, not in a >>>> public cloud at this time, but the basics are the same either way. >>>> >>>> >>>> >>>> - setup nifi as a stateful set so you can scale up or down as needed. >>>> When a pod fails, k8s will spawn another to take its place and zookeeper >>>> will manage the election of the master during transitions. >>>> >>>> - manage your certs as K8S secrets. >>>> >>>> - you also need to also have a stateful set of zookeeper pods for >>>> managing the nifi servers. >>>> >>>> - use persistent volume mounts to hold the flowfile, database, content, >>>> and provenance _repository directories >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Oct 21, 2019 at 11:21 AM Joe Gresock <[email protected]> >>>> wrote: >>>> >>>> Apologies if this has been answered on the list already.. >>>> >>>> >>>> >>>> Does anyone have knowledge of the latest in the realm of nifi >>>> kubernetes support? I see some pages like >>>> https://hub.helm.sh/charts/cetic/nifi, and >>>> https://github.com/AlexsJones/nifi but am unsure which example to pick >>>> to start with. >>>> >>>> >>>> >>>> I'm curious how well kubernetes maintains the nifi cluster state with >>>> pod failures. I.e., do any of the k8s implementations play well with the >>>> nifi cluster list so that we don't have dangling downed nodes in the >>>> cluster? Also, I'm wondering how certs are managed in a secured cluster. >>>> >>>> >>>> >>>> Appreciate any nudge in the right direction, >>>> >>>> Joe >>>> >>>> > > -- > Be on your guard; stand firm in the faith; be courageous; be strong. Do > everything in love. -*1 Corinthians 16:13-14* > -- Be on your guard; stand firm in the faith; be courageous; be strong. Do everything in love. -*1 Corinthians 16:13-14*
