I'm having some issues, trying to connect a producer container with a kafka container.
I will have 3 differents projects, each running in a docker container on the same machine :
kafka server
producer
consumer
At this moment, my Kafka's server is running well and I have just made a producer which i'm trying to send a message (only basic test).
I'm getting this error :
kafka:9092/bootstrap: Connect to ipv4#172.28.0.3:9092 failed: Connection refused
I checked multiple post/response but I'm kinda lost, I have read I needed the same network so I did it but can't figure what's else I'm missing.
Here is my Kafka server docker compose :
version: '3'
services:
laravel.test:
build:
context: ./vendor/laravel/sail/runtimes/8.1
dockerfile: Dockerfile
args:
WWWGROUP: '${WWWGROUP}'
image: sail-8.1/app
extra_hosts:
- 'host.docker.internal:host-gateway'
ports:
- '${APP_PORT:-80}:80'
environment:
WWWUSER: '${WWWUSER}'
LARAVEL_SAIL: 1
XDEBUG_MODE: '${SAIL_XDEBUG_MODE:-off}'
XDEBUG_CONFIG: '${SAIL_XDEBUG_CONFIG:-client_host=host.docker.internal}'
volumes:
- '.:/var/www/html'
networks:
- sail
depends_on:
- pgsql
pgsql:
image: 'postgres:13'
ports:
- '${FORWARD_DB_PORT:-5432}:5432'
environment:
PGPASSWORD: '${DB_PASSWORD:-secret}'
POSTGRES_DB: '${DB_DATABASE}'
POSTGRES_USER: '${DB_USERNAME}'
POSTGRES_PASSWORD: '${DB_PASSWORD:-secret}'
volumes:
- 'sail-pgsql:/var/lib/postgresql/data'
networks:
- sail
healthcheck:
test:
[
"CMD",
"pg_isready",
"-q",
"-d",
"${DB_DATABASE}",
"-U",
"${DB_USERNAME}"
]
retries: 3
timeout: 5s
zookeeper:
image: confluentinc/cp-zookeeper:latest
environment:
ZOOKEEPER_CLIENT_PORT: 2181
ZOOKEEPER_TICK_TIME: 2000
ports:
- 22181:2181
kafka:
image: confluentinc/cp-kafka:latest
depends_on:
- zookeeper
ports:
- 29092:29092
environment:
KAFKA_BROKER_ID: 1
KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
KAFKA_ADVERTISED_LISTENERS: LISTENER_INTERNAL://kafka:9092,LISTENER_EXTERNAL://localhost:29092
KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: LISTENER_INTERNAL:PLAINTEXT,LISTENER_EXTERNAL:PLAINTEXT
KAFKA_INTER_BROKER_LISTENER_NAME: LISTENER_INTERNAL
KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
networks:
- kafka
networks:
sail:
driver: bridge
kafka:
driver: bridge
volumes:
sail-pgsql:
driver: local
Here my producer :
version: '3'
services:
laravel.test:
build:
context: ./vendor/laravel/sail/runtimes/8.1
dockerfile: Dockerfile
args:
WWWGROUP: '${WWWGROUP}'
image: sail-8.1/app
extra_hosts:
- 'host.docker.internal:host-gateway'
ports:
- '${APP_PORT:-80}:80'
environment:
WWWUSER: '${WWWUSER}'
LARAVEL_SAIL: 1
XDEBUG_MODE: '${SAIL_XDEBUG_MODE:-off}'
XDEBUG_CONFIG: '${SAIL_XDEBUG_CONFIG:-client_host=host.docker.internal}'
volumes:
- '.:/var/www/html'
networks:
- sail
- proxy
depends_on:
- pgsql
pgsql:
image: 'postgres:13'
ports:
- '${FORWARD_DB_PORT:-5432}:5432'
environment:
PGPASSWORD: '${DB_PASSWORD:-secret}'
POSTGRES_DB: '${DB_DATABASE}'
POSTGRES_USER: '${DB_USERNAME}'
POSTGRES_PASSWORD: '${DB_PASSWORD:-secret}'
volumes:
- 'sail-pgsql:/var/lib/postgresql/data'
networks:
- sail
healthcheck:
test: ["CMD", "pg_isready", "-q", "-d", "${DB_DATABASE}", "-U", "${DB_USERNAME}"]
retries: 3
timeout: 5s
networks:
sail:
driver: bridge
proxy:
external:
name: server_kafka
volumes:
sail-pgsql:
driver: local
When I inspect the network I see my both container :
docker network inspect server_kafka
[
{
"Name": "server_kafka",
"Id": "6bc8ed3f604da554eeead58dca06ba8dd926673ae9683095de18a56b45bbd70f",
"Created": "2022-02-21T11:55:31.022965034+01:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.28.0.0/16",
"Gateway": "172.28.0.1"
}
]
},
"Internal": false,
"Attachable": true,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"0b4c79952626cc79e757681137523ad918b802945d82df501f7f1ad1141ca841": {
"Name": "microservice-1_laravel.test_1",
"EndpointID": "99398ddf104b8f8ce478a611e6885fba8960fd956c59938cca4fbecc8d7d21c5",
"MacAddress": "02:42:ac:1c:00:02",
"IPv4Address": "172.28.0.2/16",
"IPv6Address": ""
},
"c1bf90faa56f61432ad99e11408ea50bfeaf5fcdeca0bfd9791bf28cb9fea835": {
"Name": "server_kafka_1",
"EndpointID": "4af2450208622da0550d935332c5451c8c53a07ff10a120fb519f30cfbd157cb",
"MacAddress": "02:42:ac:1c:00:03",
"IPv4Address": "172.28.0.3/16",
"IPv6Address": ""
}
},
"Options": {},
"Labels": {
"com.docker.compose.network": "kafka",
"com.docker.compose.project": "server",
"com.docker.compose.version": "1.29.2"
}
}
]
The doc above is nice.
In my case, I was missing the network for zookeeper in my docker-compose
networks:
- kafka
Related
It's my first time deploying a project on a DigitalOcean. I've a project of one server (laravel 9 with docker and graphQl) and two clients (Vue.js 3 composition api).
I dunno how to deploy my projects and let them work on net.
I've tried creating an App on digitalOcean, connecting the project to my github repo and deploying it. It works but when I try to connect my client to the server (from locale), I get on the logs the following error .
production.ERROR: Class "Redis" not found
I don't know how to solve it.
That's my docker-compose content
laravel.test:
build:
context: ./vendor/laravel/sail/runtimes/8.1
dockerfile: Dockerfile
args:
WWWGROUP: '${WWWGROUP}'
#
image: sail-8.1/app
extra_hosts:
- 'host.docker.internal:host-gateway'
ports:
- '${APP_PORT:-80}:80'
environment:
WWWUSER: '${WWWUSER}'
LARAVEL_SAIL: 1
XDEBUG_MODE: '${SAIL_XDEBUG_MODE:-off}'
XDEBUG_CONFIG: '${SAIL_XDEBUG_CONFIG:-client_host=host.docker.internal}'
volumes:
- '.:/var/www/html'
networks:
- sail
depends_on:
- mysql
- redis
- meilisearch
- selenium
mysql:
image: 'mysql/mysql-server:8.0'
ports:
- '${FORWARD_DB_PORT:-3306}:3306'
environment:
MYSQL_ROOT_PASSWORD: '${DB_PASSWORD}'
MYSQL_ROOT_HOST: "%"
MYSQL_DATABASE: '${DB_DATABASE}'
MYSQL_USER: '${DB_USERNAME}'
MYSQL_PASSWORD: '${DB_PASSWORD}'
MYSQL_ALLOW_EMPTY_PASSWORD: 1
volumes:
- 'sail-mysql:/var/lib/mysql'
networks:
- sail
healthcheck:
test: [ "CMD", "mysqladmin", "ping", "-p${DB_PASSWORD}" ]
retries: 3
timeout: 5s
redis:
image: 'redis:alpine'
ports:
- '${FORWARD_REDIS_PORT:-6379}:6379'
volumes:
- 'sail-redis:/data'
networks:
- sail
healthcheck:
test: [ "CMD", "redis-cli", "ping" ]
retries: 3
timeout: 5s
meilisearch:
image: 'getmeili/meilisearch:latest'
ports:
- '${FORWARD_MEILISEARCH_PORT:-7700}:7700'
volumes:
- 'sail-meilisearch:/data.ms'
networks:
- sail
healthcheck:
test:
[
"CMD",
"wget",
"--no-verbose",
"--spider",
"http://localhost:7700/health"
]
retries: 3
timeout: 5s
mailhog:
image: 'mailhog/mailhog:latest'
ports:
- '${FORWARD_MAILHOG_PORT:-1025}:1025'
- '${FORWARD_MAILHOG_DASHBOARD_PORT:-8025}:8025'
networks:
- sail
selenium:
image: 'selenium/standalone-chrome'
volumes:
- '/dev/shm:/dev/shm'
networks:
- sail
Here the composer.json "require" content:
"require": {
"php": "^8.0.2",
"daniel-de-wit/lighthouse-sanctum": "^2.0",
"fruitcake/laravel-cors": "^3.0",
"guzzlehttp/guzzle": "^7.2",
"laravel/framework": "^9.2",
"laravel/sanctum": "^2.14.1",
"laravel/tinker": "^2.7",
"mll-lab/laravel-graphql-playground": "^2.6",
"nuwave/lighthouse": "^5.47",
"pusher/pusher-php-server": "^7.2"
},
Any ideas? I'm totally newbie on this.
I've been running my ECK (Elastic Cloud on Kubernetes) cluster for a couple of weeks with no issues. However, 3 days ago filebeat stopped being able to connect to my ES service. All pods are up and running (Elastic, Beats and Kibana).
Also, shelling into filebeats pods and connecting to the Elasticsearch service works just fine:
curl -k -u "user:$PASSWORD" https://quickstart-es-http.quickstart.svc:9200
{
"name" : "aegis-es-default-4",
"cluster_name" : "quickstart",
"cluster_uuid" : "",
"version" : {
"number" : "7.14.0",
"build_flavor" : "default",
"build_type" : "docker",
"build_hash" : "",
"build_date" : "",
"build_snapshot" : false,
"lucene_version" : "8.9.0",
"minimum_wire_compatibility_version" : "6.8.0",
"minimum_index_compatibility_version" : "6.0.0-beta1"
},
"tagline" : "You Know, for Search"
}
Yet the filebeats pod logs are producing the below error:
ERROR
[publisher_pipeline_output] pipeline/output.go:154
Failed to connect to backoff(elasticsearch(https://quickstart-es-http.quickstart.svc:9200)):
Connection marked as failed because the onConnect callback failed: could not connect to a compatible version of Elasticsearch:
503 Service Unavailable:
{
"error": {
"root_cause": [
{ "type": "master_not_discovered_exception", "reason": null }
],
"type": "master_not_discovered_exception",
"reason": null
},
"status": 503
}
I haven't made any changes so I think it's a case of authentication or SSL certificates needing updating?
My filebeats config looks like this:
apiVersion: beat.k8s.elastic.co/v1beta1
kind: Beat
metadata:
name: quickstart
namespace: quickstart
spec:
type: filebeat
version: 7.14.0
elasticsearchRef:
name: quickstart
config:
filebeat:
modules:
- module: gcp
audit:
enabled: true
var.project_id: project_id
var.topic: topic_name
var.subcription: sub_name
var.credentials_file: /usr/certs/credentials_file
var.keep_original_message: false
vpcflow:
enabled: true
var.project_id: project_id
var.topic: topic_name
var.subscription_name: sub_name
var.credentials_file: /usr/certs/credentials_file
firewall:
enabled: true
var.project_id: project_id
var.topic: topic_name
var.subscription_name: sub_name
var.credentials_file: /usr/certs/credentials_file
daemonSet:
podTemplate:
spec:
serviceAccountName: filebeat
automountServiceAccountToken: true
dnsPolicy: ClusterFirstWithHostNet
hostNetwork: true
securityContext:
runAsUser: 0
containers:
- name: filebeat
volumeMounts:
- name: varlogcontainers
mountPath: /var/log/containers
- name: varlogpods
mountPath: /var/log/pods
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
- name: credentials
mountPath: /usr/certs
readOnly: true
volumes:
- name: varlogcontainers
hostPath:
path: /var/log/containers
- name: varlogpods
hostPath:
path: /var/log/pods
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
- name: credentials
secret:
defaultMode: 420
items:
secretName: elastic-service-account
And it was working just fine - haven't made any changes to this config to make it lose access.
Did a little more digging and found that there weren't enough resources to be able to assign a master node.
Got this when I tried to run GET /_cat/master and it returned the same 503 no master error. I added a new node pool and it started running normally.
I am following reindex documentation here: https://www.elastic.co/guide/en/cloud/current/ec-migrate-data.html
I have two Elasticsearch indexes in localhost:
192.168.0.100:9200
{
"name" : "fses01",
"cluster_name" : "fs-es-cluster",
"cluster_uuid" : "DqVDBBafRaO9UAJPKuc_xQ",
"version" : {
"number" : "7.14.0",
"build_flavor" : "default",
"build_type" : "docker",
"build_hash" : "dd5a0a2acaa2045ff9624f3729fc8a6f40835aa1",
"build_date" : "2021-07-29T20:49:32.864135063Z",
"build_snapshot" : false,
"lucene_version" : "8.9.0",
"minimum_wire_compatibility_version" : "6.8.0",
"minimum_index_compatibility_version" : "6.0.0-beta1"
},
"tagline" : "You Know, for Search"
}
With the following index:
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open formshare_records NpEFzsGvTEmivnYjJhwHJg 5 1 51343 0 7.8mb 3.9mb
192.168.0.100:9201
{
"name" : "es01",
"cluster_name" : "es-docker-cluster",
"cluster_uuid" : "bvsRXLwZRtKuWIrIuKx0hg",
"version" : {
"number" : "7.14.2",
"build_flavor" : "default",
"build_type" : "docker",
"build_hash" : "6bc13727ce758c0e943c3c21653b3da82f627f75",
"build_date" : "2021-09-15T10:18:09.722761972Z",
"build_snapshot" : false,
"lucene_version" : "8.9.0",
"minimum_wire_compatibility_version" : "6.8.0",
"minimum_index_compatibility_version" : "6.0.0-beta1"
},
"tagline" : "You Know, for Search"
}
With the same index but blank:
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open formshare_records uxvizIAIS82YBHSsvpq4-Q 5 1 0 0 2kb 1kb
I am doing a reindex using CULR with the following:
curl -X POST "192.168.0.100:9201/_reindex" -H 'Content-Type: application/json' -d'
{
"source": {
"remote": {
"host": "http://192.168.0.100:9200"
},
"index": "formshare_records",
"query": {
"match_all": {}
}
},
"dest": {
"index": "formshare_records"
}
}
'
But I get zero transfer:
{"took":34,"timed_out":false,"total":0,"updated":0,"created":0,"deleted":0,"batches":0,"version_conflicts":0,"noops":0,"retries":{"bulk":0,"search":0},"throttled_millis":0,"requests_per_second":-1.0,"throttled_until_millis":0,"failures":[]}
The index definition is the same on both sides:
{"settings": {
"index": {
"number_of_shards": 5,
"number_of_replicas": 1
}
},
"mappings": {
"properties": {
"project_id": {"type": "keyword"},
"form_id": {"type": "keyword"},
"schema": {"type": "keyword"},
"table": {"type": "keyword"}
}
}}
Both of them are under docker:
192.168.0.100:9200
version: '3'
services:
fses01:
image: docker.elastic.co/elasticsearch/elasticsearch:7.14.0
container_name: fses01
environment:
- node.name=fses01
- cluster.name=fs-es-cluster
- discovery.seed_hosts=fses02
- cluster.initial_master_nodes=fses01,fses02
- bootstrap.memory_lock=true
- xpack.security.enabled=false
- "ES_JAVA_OPTS=-Xms2048m -Xmx2048m"
- cluster.max_shards_per_node=20000
- script.max_compilations_rate=10000/1m
ulimits:
memlock:
soft: -1
hard: -1
volumes:
- /opt/elasticsearch-docker/data:/usr/share/elasticsearch/data
ports:
- 9200:9200
networks:
- esnet
fses02:
image: docker.elastic.co/elasticsearch/elasticsearch:7.14.0
container_name: fses02
environment:
- node.name=fses02
- cluster.name=fs-es-cluster
- discovery.seed_hosts=fses01
- cluster.initial_master_nodes=fses01,fses02
- bootstrap.memory_lock=true
- xpack.security.enabled=false
- "ES_JAVA_OPTS=-Xms2048m -Xmx2048m"
- cluster.max_shards_per_node=20000
- script.max_compilations_rate=10000/1m
ulimits:
memlock:
soft: -1
hard: -1
volumes:
- /opt/elasticsearch-docker/data2:/usr/share/elasticsearch/data
networks:
- esnet
kib01:
image: docker.elastic.co/kibana/kibana:7.14.0
container_name: kib01
ports:
- 5601:5601
environment:
ELASTICSEARCH_URL: http://fses01:9200
ELASTICSEARCH_HOSTS: '["http://fses01:9200","http://fses02:9200"]'
networks:
- esnet
networks:
esnet:
192.168.0.100:9201
version: '3.7'
services:
es01:
image: docker.elastic.co/elasticsearch/elasticsearch:7.14.2
container_name: es01
environment:
- node.name=es01
- cluster.name=es-docker-cluster
- discovery.seed_hosts=es02,es03
- cluster.initial_master_nodes=es01,es02,es03
- bootstrap.memory_lock=true
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
- reindex.remote.whitelist=192.168.0.100:9200
ulimits:
memlock:
soft: -1
hard: -1
volumes:
- /opt/elasticsearch710/data:/usr/share/elasticsearch/data
ports:
- 9201:9200
networks:
- elastic
es02:
image: docker.elastic.co/elasticsearch/elasticsearch:7.14.2
container_name: es02
environment:
- node.name=es02
- cluster.name=es-docker-cluster
- discovery.seed_hosts=es01,es03
- cluster.initial_master_nodes=es01,es02,es03
- bootstrap.memory_lock=true
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
ulimits:
memlock:
soft: -1
hard: -1
volumes:
- /opt/elasticsearch710/data2:/usr/share/elasticsearch/data
networks:
- elastic
es03:
image: docker.elastic.co/elasticsearch/elasticsearch:7.14.2
container_name: es03
environment:
- node.name=es03
- cluster.name=es-docker-cluster
- discovery.seed_hosts=es01,es02
- cluster.initial_master_nodes=es01,es02,es03
- bootstrap.memory_lock=true
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
ulimits:
memlock:
soft: -1
hard: -1
volumes:
- /opt/elasticsearch710/data3:/usr/share/elasticsearch/data
networks:
- elastic
networks:
elastic:
driver: bridge
The container of 9201 can see the index of 9200:
sudo docker exec -it es01 /bin/bash
[root#943159977b17 elasticsearch]# curl -X GET "192.168.0.100:9200/_cat/indices/formshare_records?v&s=index&pretty"
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open formshare_records NpEFzsGvTEmivnYjJhwHJg 5 1 51343 0 7.8mb 3.9mb
curl -X POST "192.168.0.100:9201/_reindex" -H 'Content-Type: application/json' -d'
{
"source": {
"remote": {
"host": "http://192.168.0.100:9200"
},
"index": "formshare_records",
"query": {
"match_all": {}
}
},
"dest": {
"index": "formshare_records"
}
}
'
{"took":18,"timed_out":false,"total":0,"updated":0,"created":0,"deleted":0,"batches":0,"version_conflicts":0,"noops":0,"retries":{"bulk":0,"search":0},"throttled_millis":0,"requests_per_second":-1.0,"throttled_until_millis":0,"failures":[]}
Any idea why reindex does not work? I tried without query but I get the same!
I have had success before specifying the hosts in my elasticsearch.yaml file by IP (hardcoding address:port) but I was told this is bad practice. I am trying to switch to using just the pod names for my ES cluster and now the pods aren't discovered/used as master. I have a elasticsearch.yml configMap for all 3 pods that I mount which has the following specs:
cluster.name: elasticsearch-logs
node.name: ${HOSTNAME}
node.master: true
node.data: true
network.host: _local_
transport.tcp.port: 9300
http.port: 9200
bootstrap.memory_lock: false
xpack.security.enabled: false
discovery.zen.minimum_master_nodes: 2
discovery.zen.ping.unicast.hosts: ["es-0:9300", "es-1:9300", "es-2:9300"]
Along with this I have 2 services. One is a headless service and the other is a ClusterIP.
apiVersion: v1
kind: Service
metadata:
name: elasticsearch-svc
labels:
component: elasticsearch
role: master
spec:
selector:
component: elasticsearch
role: master
ports:
- name: transport
port: 9300
targetPort: 9300
clusterIP: None
apiVersion: v1
kind: Service
metadata:
name: elasticsearch-discovery
labels:
component: elasticsearch
role: master
spec:
selector:
component: elasticsearch
role: master
ports:
- name: transport
port: 9300
protocol: TCP
And in the main StatefulSet file that creates the ES pods I have the port specs:
ports:
- containerPort: 9200
name: db
protocol: TCP
- containerPort: 9300
name: transport
protocol: TCP
I am trying to get all 3 pods to act as master (and data/client). When I look at one of pod logs (here es-0) after creating my services/statefulsets I see the following repeating errors:
[2017-10-16T15:31:29,078][WARN ][o.e.d.z.UnicastZenPing ] [es-0] timed out after [5s] resolving host [es-1:9300]
[2017-10-16T15:31:29,079][WARN ][o.e.d.z.UnicastZenPing ] [es-0] timed out after [5s] resolving host [es-2:9300]
[2017-10-16T15:31:32,080][WARN ][o.e.d.z.ZenDiscovery ] [es-0] not enough master nodes discovered during pinging (found [[Candidate{node={es-0}{TUE-h8SNR6q7WbWUl2Pm-A}{XrTrBg3ATqSvlB3hTlezpg}{172.17.0.3}{172.17.0.3:9300}{ml.max_open_jobs=10, ml.enabled=true}, clusterStateVersion=-1}]], but needed [2]), pinging again
[2017-10-16T15:31:36,111][WARN ][o.e.d.z.UnicastZenPing ] [es-0] failed to resolve host [es-1:9300]
java.net.UnknownHostException: es-1
at java.net.InetAddress.getAllByName0(InetAddress.java:1280) ~[?:1.8.0_141]
at java.net.InetAddress.getAllByName(InetAddress.java:1192) ~[?:1.8.0_141]
at java.net.InetAddress.getAllByName(InetAddress.java:1126) ~[?:1.8.0_141]
at org.elasticsearch.transport.TcpTransport.parse(TcpTransport.java:908) ~[elasticsearch-5.6.3.jar:5.6.3]
at org.elasticsearch.transport.TcpTransport.addressesFromString(TcpTransport.java:863) ~[elasticsearch-5.6.3.jar:5.6.3]
at org.elasticsearch.transport.TransportService.addressesFromString(TransportService.java:691) ~[elasticsearch-5.6.3.jar:5.6.3]
at org.elasticsearch.discovery.zen.UnicastZenPing.lambda$null$0(UnicastZenPing.java:212) ~[elasticsearch-5.6.3.jar:5.6.3]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_141]
at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:569) [elasticsearch-5.6.3.jar:5.6.3]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_141]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_141]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_141]
[2017-10-16T15:31:36,116][WARN ][o.e.d.z.UnicastZenPing ] [es-0] failed to resolve host [es-2:9300]
java.net.UnknownHostException: es-2
at java.net.InetAddress.getAllByName0(InetAddress.java:1280) ~[?:1.8.0_141]
at java.net.InetAddress.getAllByName(InetAddress.java:1192) ~[?:1.8.0_141]
at java.net.InetAddress.getAllByName(InetAddress.java:1126) ~[?:1.8.0_141]
at org.elasticsearch.transport.TcpTransport.parse(TcpTransport.java:908) ~[elasticsearch-5.6.3.jar:5.6.3]
at org.elasticsearch.transport.TcpTransport.addressesFromString(TcpTransport.java:863) ~[elasticsearch-5.6.3.jar:5.6.3]
at org.elasticsearch.transport.TransportService.addressesFromString(TransportService.java:691) ~[elasticsearch-5.6.3.jar:5.6.3]
at org.elasticsearch.discovery.zen.UnicastZenPing.lambda$null$0(UnicastZenPing.java:212) ~[elasticsearch-5.6.3.jar:5.6.3]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_141]
at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:569) [elasticsearch-5.6.3.jar:5.6.3]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_141]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_141]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_141]
[2017-10-16T15:31:39,120][WARN ][o.e.d.z.ZenDiscovery ] [es-0] not enough master nodes discovered during pinging (found [[Candidate{node={es-0}{TUE-h8SNR6q7WbWUl2Pm-A}{XrTrBg3ATqSvlB3hTlezpg}{172.17.0.3}{172.17.0.3:9300}{ml.max_open_jobs=10, ml.enabled=true}, clusterStateVersion=-1}]], but needed [2]), pinging again
I am still able to reach elasticsearch through the browser at node-ip:node-port but I get 503 errors once I try and do /_cluster/state
I believe I have an error on the "networking" side with the ports but I'm not sure where exactly. What should I look into? Thanks!
StatefulSet
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
name: es
labels:
component: elasticsearch
role: master
spec:
serviceName: elasticsearch
replicas: 3
template:
metadata:
labels:
component: elasticsearch
role: master
annotations:
pod.alpha.kubernetes.io/init-containers: '[
{
"name": "init-sysctl",
"image": "alpine:3.4",
"imagePullPolicy": "IfNotPresent",
"command": ["sysctl", "-w", "vm.max_map_count=262144"],
"securityContext": {
"privileged": true
}
}
]'
spec:
subdomain: elasticsearch-svc
containers:
- name: es-master
securityContext:
privileged: true
capabilities:
add:
- IPC_LOCK
image: docker.elastic.co/elasticsearch/elasticsearch:5.6.3
imagePullPolicy: Always
env:
- name: "ES_JAVA_OPTS"
value: "-Xms512m -Xmx512m"
ports:
- containerPort: 9200
name: http
protocol: TCP
- containerPort: 9300
name: transport
protocol: TCP
volumeMounts:
- name: storage
mountPath: /data
- name: config-volume
mountPath: /usr/share/elasticsearch/config/elasticsearch.yml
subPath: elasticsearch.yml
volumes:
- name: config-volume
configMap:
name: elasticsearch-config
volumeClaimTemplates:
- metadata:
name: storage
annotations:
volume.beta.kubernetes.io/storage-class: standard
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 12Gi
You need to connect with the full dns name:
es-0.elasticsearch-internal:9300
The issue is I cannot create a deployment spec without creating replication controller along with it.I would not like to use replication controller because my app always use only one pod and I would like to set restart policy to never to prevent any terminated container tries to restart.
apiVersion: v1
kind: Pod
metadata:
name: two-containers
spec:
restartPolicy: Never
volumes:
- name: shared-data
emptyDir: {}
containers:
- name: nginx-container
image: nginx
volumeMounts:
- name: shared-data
mountPath: /usr/share/nginx/html
- name: debian-container
image: debian
volumeMounts:
- name: shared-data
mountPath: /pod-data
command: ["/bin/sh"]
args: ["-c", "echo Hello from the debian container > /pod-data/index.html"]
Above is the target yaml file, which I would like to implement and deploy with kubernetes client-go, however client-go currently only provides deployment with replication controller.
// Define Deployments spec.
deploySpec := &v1beta1.Deployment{
TypeMeta: unversioned.TypeMeta{
Kind: "Deployment",
APIVersion: "extensions/v1beta1",
},
ObjectMeta: v1.ObjectMeta{
Name: "binary-search",
},
Spec: v1beta1.DeploymentSpec{
Replicas: int32p(1),
Template: v1.PodTemplateSpec{
ObjectMeta: v1.ObjectMeta{
Name: appName,
Labels: map[string]string{"app": appName},
},
Spec: v1.PodSpec{
Containers: []v1.Container{
v1.Container{
Name: "nginx-container",
Image: "nginx",
VolumeMounts: []v1.VolumeMount{
v1.VolumeMount{
MountPath: "/usr/share/nginx/html",
Name: "shared-data",
},
},
},
v1.Container{
Name: "debian-container",
Image: "debian",
VolumeMounts: []v1.VolumeMount{
v1.VolumeMount{
MountPath: "/pod-data",
Name: "shared-data",
},
},
Command: []string{
"/bin/sh",
},
Args: []string{
"-c",
"echo Hello from the debian container > /pod-data/index1.html",
},
},
},
RestartPolicy: v1.RestartPolicyAlways,
DNSPolicy: v1.DNSClusterFirst,
Volumes: []v1.Volume{
v1.Volume{
Name: "shared-data",
VolumeSource: v1.VolumeSource{
EmptyDir: &v1.EmptyDirVolumeSource{},
},
},
},
},
},
},
}
// Implement deployment update-or-create semantics.
deploy := c.Extensions().Deployments(namespace)
_, err := deploy.Update(deploySpec)
Any suggestion? Many thanks in advance!
If you don't want the service to be restarted, then you can just use the Pod directly. There is no need to use a Deployment, since these only make sense, if you want to have automatic Pod restarts and roll-outs of updates.
The code would look somehow like this (not tested):
podSpec := v1.PodSpec{
Containers: []v1.Container{
v1.Container{
Name: "nginx-container",
Image: "nginx",
VolumeMounts: []v1.VolumeMount{
v1.VolumeMount{
MountPath: "/usr/share/nginx/html",
Name: "shared-data",
},
},
},
v1.Container{
Name: "debian-container",
Image: "debian",
VolumeMounts: []v1.VolumeMount{
v1.VolumeMount{
MountPath: "/pod-data",
Name: "shared-data",
},
},
Command: []string{
"/bin/sh",
},
Args: []string{
"-c",
"echo Hello from the debian container > /pod-data/index1.html",
},
},
},
RestartPolicy: v1.RestartPolicyAlways,
DNSPolicy: v1.DNSClusterFirst,
Volumes: []v1.Volume{
v1.Volume{
Name: "shared-data",
VolumeSource: v1.VolumeSource{
EmptyDir: &v1.EmptyDirVolumeSource{},
},
},
},
}
// Implement deployment update-or-create semantics.
deploy := c.Core().PodsGetter(namespace)
_, err := deploy.Update(podSpec)