What is etcd?

Learn more about etcd with free guide: ibm.biz/etcd-guide
Get more insights about Kubernetes: ibm.biz/free-guide-to-kubernetes
Checkout IBM Cloud Databases for etcd: ibm.biz/ibm-cloud-databases-fo...
► Earn a badge with FREE interactive, browser-based Kubernetes labs: ibm.biz/free-kube-browser-base...
How can you ensure that your data is stored consistently and reliably across a distributed system?
In this lightboard video, Whitney Lee with IBM Cloud, breaks down how etcd, an open source distributed key-value store, can reliably hold and manage your critical information that needs to be accessed by a distributed system or cluster of machines.
Get started on IBM Cloud at no cost: ibm.biz/start-ibm-cloud-for-free
#etcd #Kubernetes #Database

[@ReflectionOcean]

etcd is 1. replicated: each node in an etcd cluster has full access to the whole data store 2. consistent: every read is going to return the most recent write 3. highly available: no single point of failure and tolerance of network partition 4. fast: the speed upper bound of etcd is the individual node storage speed 5. secured: transport layer SSL 6. simple: http with JSON

[@ReflectionOcean]

When writing: 1. client makes a write request to the leader node 2. leader node forwards the request to its followers 3. followers make updates to their values 4. followers return success to the leader when values are updated 5. leader updates its own value when majority of the followers are updated successfully 6. leader returns success to the client

[@bhaaratsharma6023]

Precise and to the point introduction. Thank you.

[@aliakseibulhak]

really love this short explanation videos. thanks you IBM

[@umutsatrgurbuz8899]

Thank you for the video, great information, easy to follow.

[@ritu96patel]

Great explanation! thanks for sharing

[@shwetabhshekhar1282]

Clear and Concise. Thanks a lot.

[@fernandopenia7002]

Perfectly explained. Thank you.

[@IBMTechnology]

Thanks for watching, Fernando!

[@ReflectionOcean]

When reading from a follower that's not yet updated: 1. client makes a request to a follower 2. follower forwards the request to the leader 3. leader returns the latest value to the follower 4. follower returns the latest value to the client

[@lequocthinh8992]

So every node forward the request to the leader?

[@mattvermeer3568]

Terrific explanation. Thank you.

[@IBMTechnology]

You're welcome, Matt! 👍

[@beneditomarques4062]

Best explanaiton about etcd!

[@denysbondarenko777]

Well explained, thanks 💚

[@evanturro5458]

Great video, thanks!

[@ReflectionOcean]

K8S uses etcd "watch" function to compare configuration (desired) and state (actual)

[@expatExperience]

Great explanation

[@kausikcs9913]

This session is really helpful to get started with the etcd understanding. I have one question though, How long does it take for the changes to reflect to the web applications. Lets say in case of a change to the key-value, can the web application listening to the etcd gets the latest instatly? just like in zookeeper.

[@SanjayBudhala]

No, until the majority of follower nodes are updated with latest data & send the confirmation to the leader node, latest data cant be read.

[@ReflectionOcean]

The speed upper bound of etcd is the individual node storage speed

[@intelsc1287]

Great job! Always tough of public speaking.

[@FelipeRodrigues-lj1el]

Thank you

[@cschandragiri]

etcd types coordination services are meant for heavy read workloads, wouldn't redirecting read requests to leader to get latest state make it slow. Also, why can't all requests which need strong read consistency go to leader directly instead?

[@Jamillo]

Hi! Around 3:00, is said that the follower node knows it and will forward read requests to the leader. But, wouldn't that stress the leader. I mean, it can't be that simple.

[@tomduffin8076]

I was just thinking exactly the same thing.

[@IBMTechnology]

Hi Jamillo, thank you for the question and apologies for the delayed response. Do clients have to send requests to the etcd leader? Raft is leader-based; the leader handles all client requests which need cluster consensus. However, the client does not need to know which node is the leader. Any request that requires consensus sent to a follower is automatically forwarded to the leader. Requests that do not require consensus (e.g., serialized reads) can be processed by any cluster member. Source: etcd.io/docs/v3.4.0/faq/

[@justinkim7202]

Well you could say it's a tradeoff for being strongly consistent. It achieves strong consistency by having its leader who has the most recent data to respond to the request. Refer to the raft consensus algorithm which etcd implements.

[@blasttrash]

good question. This stresses the leader and makes me think why even have followers if for each client request, follower goes back crying to leader for answer. whats the point of having a follower if it always relies on leader and puts too much stress on leader? lol

[@r_chauhan]

@@blasttrash The followers ensure high availability and the consensus algorithm adds reliability to it. In case the leader goes down, the data is still safe and any other follower can become the leader. The raft consensus mechanism also ensures that only nodes with the most recent "commited" data become the next leader. Hence the redundant data and followers.

[@ruslanshamsiev6528]

Thank you )

[@Edu4Dev]

tks for sharing :)

[@rickharold7884]

Awesome.

[@anoopnegi4886]

In our etcd cluster we observing that etcd consuming memory and it consumed 2gb after which process killed due to OOM, and without traffic memory stay occupied. Why this issue coming??

[@vikasvishwakarma3622]

The leader will update itself only when the quorum is met i.e. 2/3 or 3/3 nodes(as per configuration) returns positive update.

[@ReflectionOcean]

etcd nodes are organized as leader and followers manner

[@jawardsally1186]

As I have understood this, etcd satisfy C and A in CAP theoram. Is it possible?

[@sbkpilot1]

a bit confused about this... so if a follower node always has to check with the leader why not directly query the leader node for the info? Does this implicitly mean that to reduce latency it is better to directly query the leader?

[@niceperson6412]

I was also wondering if we always have to ask leader, does it add a lot more burden to the leader node?

[@SanjayBudhala]

periodically the leader sends heartbeats to the follower nodes & sends small impt data with it. This is not a complete explanation a lot is happening behind the bars but answers you query. Follower nodes do query leaders directly using read index protocol but they only do it when they are not sure that they have the latest data.

[@ReflectionOcean]

etcd stores k8s data for state, configuration and metadata

[@RahulKumar-ed1bt]

Its interesting , i would like to see how k8s store data in this , which are collections used for storage inside etcd , can we query etcd in k8s cluster and directly change the data there ? I know that etcd is the brain for k8s cluster but what i see most of the time , it is hidden component for every user and they never connect to etcd , neither query that etc. ! Rather only 1 statement is taught everywhere ok all these states are maintained in etcd and it is single source of truth for anything

[@thissuper7051]

So, how does ETCD vote? When the follower is available, can he vote for himself?

[@vinitsunita]

Since etcd persist data on disk, its performance must be tied to disk and it must not be as good as redis in terms of performance of read and write operation because Redis completely holds data in memory as it is inmemory distributed cache

[@lindilebangose7667]

Both have the exact same functionality, by default etcd stores data in memory and periodically persists snapshots to disk. I don't have the data to comment on performance, but the fact that the k8s team chose it instead should highlight that it does have some advantages over Redis, namely it's consensus strategy that ensure data consistency across all nodes.

[@GauravKumar-sr6bt]

If the follower is going to route read requests through leader node (as talked in this video), what is the point of replication and having followers?

[@tempofatal]

fault tolerance

[@VikramKumar-qo3rg]

What happens if the master goes down and based on the votes the slave that has the inconsistent data 7 is elected as master? Is this inconsistency overcome in any way? Or it's not a fair question since the inconsistency would be for a very short period of time and would attain consistency eventually during this upgrade from slave to master process? Anyone who has an idea on this please?

[@aakash20202020]

voting algorithm is such that 7 will never be elected as leader as it has stale data ..Election can be based on latest updated timestamp of the followers.

[@medievalogic]

So etcd violates CAP? how is this possible?

[@user-fy4yk8gu4b]

Takes skills to precisely and concisely teach the concepts, all while writing backwards

[@nithchea9936]

Every technology teaching video, there is always positivity in the comment section.

[@ronaldmariah]

When the followers had the values 17, 17, 7. And the leader subsequently went down. What's in place for the follower (7) not being elected and replicating a stale value?

[@blasttrash]

good question. In the video She conveniently changed 7 to 17 when that happened. if a network partition occurred and all "17" nodes went down and only "7" nodes are left, we will have wrong data, this is not explained in this video. Not sure how they tackle this edge case.

[@r_chauhan]

The raft consensus mechanism has a rule that prevents nodes from voting for nodes with older data than theirs, hence only nodes that have recent data can become a leader.

[@christopherraymond8382]

Did I miss the part where she explained what happens when nodes try to rejoin the cluster? She mentioned the case where the mast went down, then never described what happens if/when that node comes back.

[@alanwright376]

The presentation was high level. The term (session) of a rejoining node will be stale or it will not have an up-to-date commit log, which means it has to be a follower and defer to the current leader. Since followers always have to validate with the leader, it behaves similar to existing followers.

[@JusesChrost]

The squeeky sound when you write on that board is unnecessory, other than that, perfect video.

[@niceperson6412]

Is this called read repair?

[@einfacherkerl3279]

please describe zookeeper also

[@Soulseeologia]

How much does this cost?

[@linxianer12]

Etcd ? Etcd is free and open source.

[@somakkamos]

if etcd is so great why not use it as distributed database for all purposes?? whats the catch here?

[@PurnachandMedisetty]

5:52 what went down there.

[@mxmstrj]

Are we just going to pretend that she isn't writing everything out backwards better than most people write normally

[@mxmstrj]

I think they recorded it normally then horizontality flipped the video

[@trailblazingfive]

tl;dr => etcd is an open source key value data store

[@PaulPetersVids]

Uh... quick question. Is she writing backwards?

[@guyemry7947]

right!? I am surprised there aren't more comments about this! That's impressive!

[@cesar_zapata]

This is how it can be made: kzbin.info/www/bejne/fIraiYKCipmHgc0

[@SantoshKumar-yg2xt]

Doesn't look like etcd is good for decentralised systems. There always needs to be a leader?

[@saurabhjha8733]

IBM videos are either too broad or too esoteric